RT 3.4.2/3.4.3 Perl dependencies problem

RT Users
1

Hi,

I successfully installed RT 3.4.2 several months ago on a CentOS 4
system. I used the RHEL4 install guide located on the Wiki to perfect
success with Postgresql. Since then, I’ve even upgraded to 3.4.3 with no
problems, installed RTFM, etc. I haven’t had any issues with the working
box.

I’m attempting to duplicate a testserver setup using the same CentOS 4
server OS. I cannot get 3.4.2 or 3.4.3 to load properly using the exact
same system. I’ve tried with Postgresql and Mysql to no avail. I’ve
duplicated all installed packages as the working machine, followed the
exact same steps on the wiki, etc.

By using the perl sbin/rt-test-dependencies setup, Perl keeps going only
so far as to stop at the end with the following missing packages:

[root@testserver rt-3.4.3]# perl sbin/rt-test-dependencies
–with-postgresql --with-fastcgi --verbose | grep MISSING
DBIx::SearchBuilder 1.26…MISSING
WWW::Mechanize …MISSING
Test::WWW::Mechanize …MISSING

These absolutely will not install without a force. I went back to my
working machine and was able to locate around 75 Perl packages that I
have installed, that have newer versions available. So, when I’m
attempting to load it now, it’s dragging down the latest versions. I’m
wondering if something with the Perl dependencies has changed, or if
anyone else has experienced anything similar?

Thanks,
Max

2

[root@testserver rt-3.4.3]# perl sbin/rt-test-dependencies --with-
postgresql --with-fastcgi --verbose | grep MISSING
DBIx::SearchBuilder 1.26…MISSING
WWW::Mechanize …MISSING
Test::WWW::Mechanize …MISSING

These absolutely will not install without a force.

If the problem you were having was that these three modules would not
pass tests, perhaps you should give more details?

–dave
Code Monkey, Best Practical Solutions
David Glasser | glasser@bestpractical.com

3

-----Original Message-----

By using the perl sbin/rt-test-dependencies setup, Perl keeps
going only so far as to stop at the end with the following
missing packages:

[root@testserver rt-3.4.3]# perl sbin/rt-test-dependencies
–with-postgresql --with-fastcgi --verbose | grep MISSING
DBIx::SearchBuilder 1.26…MISSING
WWW::Mechanize …MISSING
Test::WWW::Mechanize …MISSING

I had problems with the last two as well recently… I don’t know if it was wise or not, but I did a “force install” from within CPAN, and it ended up working. Haven’t seen any errors due to this, yet anyways.

Cheers, Bjorn

4

David Glasser wrote:

If the problem you were having was that these three modules would not
pass tests, perhaps you should give more details?

When I attempt to install DBIx::SearchBuilder I get this error:

make[1]: Leaving directory `/root/.cpan/build/Test-Simple-0.60’
/usr/bin/make test – NOT OK
Running make install
make test had returned bad status, won’t install without force
*** Test::More installation failed.
*** ExtUtils::AutoInstall installation finished.
PERL_DL_NONLAZY=1 /usr/bin/perl “-MExtUtils::Command::MM” “-e”
“test_harness(0, ‘inc’, ‘blib/lib’, ‘blib/arch’)” t/00.load.t
t/01basics.t t/01nocap_api.t t/01records.t t/01searches.t
t/02records_object.t t/03rebless.t t/10schema.t t/11schema_records.t t/pod.t
t/00.load…ok
1/12 skipped: DBD::Oracle is not installed
t/01basics…ok
t/01nocap_api…skipped
all skipped: capitalization pragma is not installed
t/01records…ok
130/130 skipped: various reasons
t/01searches…ok
118/118 skipped: various reasons
t/02records_object…ok
22/22 skipped: various reasons
t/03rebless…ok
8/8 skipped: various reasons
t/10schema…ok 2/31Warning: Use of “require” without
parentheses is ambiguous at (eval 14) line 2.
t/10schema…NOK 3# Failed test (t/10schema.t at line 25)

Tried to require ‘t/testmodels.pl’.

Error: Search pattern not terminated at (eval 14) line 2.

t/10schema…ok 31/31# Looks like you failed 1 tests of 31.
t/10schema…dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 3
Failed 1/31 tests, 96.77% okay (less 28 skipped tests: 2 okay,
6.45%)
t/11schema_records…ok
126/126 skipped: various reasons
t/pod…ok
Failed Test Stat Wstat Total Fail Failed List of Failed
t/10schema.t 1 256 31 1 3.23% 3
1 test and 433 subtests skipped.
Failed 1/10 test scripts, 90.00% okay. 1/470 subtests failed, 99.79% okay.
make: *** [test_dynamic] Error 255
/usr/bin/make test – NOT OK
Running make install
make test had returned bad status, won’t install without force

When I try to load Test::WWW::Mechanize or WWW::Mechanize I get this:

CPAN: Storable loaded ok
Going to read /root/.cpan/Metadata
Database was generated on Mon, 22 Aug 2005 23:08:52 GMT
Running install for module Test::WWW::Mechanize
Running make for P/PE/PETDANCE/Test-WWW-Mechanize-1.06.tar.gz
CPAN: Digest::MD5 loaded ok
Checksum for
/root/.cpan/sources/authors/id/P/PE/PETDANCE/Test-WWW-Mechanize-1.06.tar.gz
ok
Scanning cache /root/.cpan/build for sizes
Test-WWW-Mechanize-1.06/
Test-WWW-Mechanize-1.06/Changes
Test-WWW-Mechanize-1.06/Makefile.PL
Test-WWW-Mechanize-1.06/MANIFEST
Test-WWW-Mechanize-1.06/Mechanize.pm
Test-WWW-Mechanize-1.06/META.yml
Test-WWW-Mechanize-1.06/README
Test-WWW-Mechanize-1.06/t/
Test-WWW-Mechanize-1.06/t/00load.t
Test-WWW-Mechanize-1.06/t/content_contains.t
Test-WWW-Mechanize-1.06/t/content_lacks.t
Test-WWW-Mechanize-1.06/t/follow_link_ok.t
Test-WWW-Mechanize-1.06/t/get_ok-parms.t
Test-WWW-Mechanize-1.06/t/get_ok.t
Test-WWW-Mechanize-1.06/t/has_tag.t
Test-WWW-Mechanize-1.06/t/html/
Test-WWW-Mechanize-1.06/t/html/badlinks.html
Test-WWW-Mechanize-1.06/t/html/form.html
Test-WWW-Mechanize-1.06/t/html/goodlinks.html
Test-WWW-Mechanize-1.06/t/link_content.t
Test-WWW-Mechanize-1.06/t/link_status.t
Test-WWW-Mechanize-1.06/t/links_ok.t
Test-WWW-Mechanize-1.06/t/new.t
Test-WWW-Mechanize-1.06/t/page_links_content.t
Test-WWW-Mechanize-1.06/t/page_links_ok.t
Test-WWW-Mechanize-1.06/t/pod-coverage.t
Test-WWW-Mechanize-1.06/t/pod.t
Test-WWW-Mechanize-1.06/t/stuff_inputs.t
Removing previously used /root/.cpan/build/Test-WWW-Mechanize-1.06
CPAN.pm: Going to build P/PE/PETDANCE/Test-WWW-Mechanize-1.06.tar.gz

Checking if your kit is complete…
Looks good
Writing Makefile for Test::WWW::Mechanize
---- Unsatisfied dependencies detected during
[P/PE/PETDANCE/Test-WWW-Mechanize-1.06.tar.gz] -----
WWW::Mechanize
Shall I follow them and prepend them to the queue
of modules we are processing right now? [yes] Running make test
Delayed until after prerequisites
Running make install
Delayed until after prerequisites
Running install for module WWW::Mechanize
Running make for P/PE/PETDANCE/WWW-Mechanize-1.12.tar.gz
Checksum for
/root/.cpan/sources/authors/id/P/PE/PETDANCE/WWW-Mechanize-1.12.tar.gz ok
WWW-Mechanize-1.12/
WWW-Mechanize-1.12/Changes
WWW-Mechanize-1.12/MANIFEST
WWW-Mechanize-1.12/META.yml
WWW-Mechanize-1.12/lib/
WWW-Mechanize-1.12/lib/WWW/
WWW-Mechanize-1.12/lib/WWW/Mechanize/
WWW-Mechanize-1.12/lib/WWW/Mechanize/Image.pm
WWW-Mechanize-1.12/lib/WWW/Mechanize/FAQ.pod
WWW-Mechanize-1.12/lib/WWW/Mechanize/Examples.pod
WWW-Mechanize-1.12/lib/WWW/Mechanize/Cookbook.pod
WWW-Mechanize-1.12/lib/WWW/Mechanize/Link.pm
WWW-Mechanize-1.12/lib/WWW/Mechanize.pm
WWW-Mechanize-1.12/bin/
WWW-Mechanize-1.12/bin/mech-dump
WWW-Mechanize-1.12/etc/
WWW-Mechanize-1.12/etc/www-mechanize-logo.png
WWW-Mechanize-1.12/t/
WWW-Mechanize-1.12/t/warn.t
WWW-Mechanize-1.12/t/image-parse.t
WWW-Mechanize-1.12/t/pod.t
Running make test
PERL_DL_NONLAZY=1 /usr/bin/perl “-MExtUtils::Command::MM” “-e”
“test_harness(0, ‘blib/lib’, ‘blib/arch’)” t/00.load.t t/add_header.t
t/aliases.t t/area_link.t t/autocheck.t t/clone.t t/die.t t/field.t
t/find_image.t t/find_link-warnings.t t/find_link.t t/form-parsing.t
t/frames.t t/image-new.t t/image-parse.t t/link-base.t t/link-relative.t
t/link.t t/mech-dump.t t/new.t t/pod-coverage.t t/pod.t t/regex-error.t
t/select.t t/taint.t t/tick.t t/upload.t t/warn.t t/warnings.t
t/local/back.t t/local/click.t t/local/click_button.t t/local/failure.t
t/local/follow.t t/local/form.t t/local/get.t t/local/overload.t
t/local/page_stack.t t/local/referer.t t/local/reload.t t/local/submit.t
t/live/back.t t/live/click.t t/live/follow.t t/live/follow_link.t
t/live/form.t t/live/get.t t/live/reload.t t/live/submit.t
t/00.load…ok
t/add_header…ok
t/aliases…ok
t/area_link…ok
t/autocheck…ok
t/clone…ok
t/autocheck…ok
t/clone…ok
t/die…ok
t/field…ok
t/find_image…ok
t/find_link-warnings…ok
t/find_link…ok
t/form-parsing…ok
t/frames…ok
t/image-new…ok
t/image-parse…ok
t/link-base…ok
t/link-relative…ok
t/link…ok
t/live/back…dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 12
Failed 1/32 tests, 96.88% okay
t/live/click…ok
t/live/follow…ok
t/live/follow_link…ok
t/live/form…ok
t/live/get…dubious
Test returned status 9 (wstat 2304, 0x900)
DIED. FAILED tests 15-17, 19-22, 24-25
Failed 9/26 tests, 65.38% okay
t/live/reload…ok
t/live/submit…ok
t/local/back…ok
t/local/click…ok
t/local/click_button…ok
t/local/failure…ok
t/local/follow…ok
t/local/form…ok
t/local/get…ok
t/local/overload…ok
t/local/page_stack…ok
t/local/referer…ok
t/local/page_stack…ok
t/local/referer…ok
t/local/reload…ok
t/local/submit…ok
t/mech-dump…ok
t/new…ok
t/pod-coverage…ok
t/pod…ok
t/regex-error…ok
t/select…ok
t/taint…skipped
all skipped: Test::Taint required for checking taintedness
t/tick…ok
t/upload…ok
t/warn…ok
t/warnings…ok
Failed Test Stat Wstat Total Fail Failed List of Failed
t/live/back.t 1 256 32 1 3.12% 12
t/live/get.t 9 2304 26 9 34.62% 15-17 19-22 24-25
1 test skipped.
/usr/bin/make test – NOT OK
Running make install
make test had returned bad status, won’t install without force
Running make for P/PE/PETDANCE/Test-WWW-Mechanize-1.06.tar.gz
Is already unwrapped into directory
/root/.cpan/build/Test-WWW-Mechanize-1.06

CPAN.pm: Going to build P/PE/PETDANCE/Test-WWW-Mechanize-1.06.tar.gz

cp Mechanize.pm blib/lib/Test/WWW/Mechanize.pm
Manifying blib/man3/Test::WWW::Mechanize.3pm
/usr/bin/make – OK
Running make test
PERL_DL_NONLAZY=1 /usr/bin/perl “-MExtUtils::Command::MM” “-e”
“test_harness(0, ‘blib/lib’, ‘blib/arch’)” t/*.t
t/00load…dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
t/content_contains…dubious
Test returned status 4 (wstat 1024, 0x400)
DIED. FAILED tests 1, 3-5
Failed 4/5 tests, 20.00% okay
t/content_lacks…dubious
Test returned status 4 (wstat 1024, 0x400)
DIED. FAILED tests 1, 3-5
Failed 4/5 tests, 20.00% okay
t/follow_link_ok…dubious
Test returned status 5 (wstat 1280, 0x500)
DIED. FAILED tests 1, 3-6
Failed 5/6 tests, 16.67% okay
t/get_ok-parms…dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 1-16
Failed 16/16 tests, 0.00% okay
t/get_ok…dubious
Test returned status 10 (wstat 2560, 0xa00)
DIED. FAILED tests 1, 3-11
Failed 10/11 tests, 9.09% okay
t/has_tag…dubious
Test returned status 6 (wstat 1536, 0x600)
DIED. FAILED tests 1, 3-7
Failed 6/7 tests, 14.29% okay
t/link_content…dubious
Test returned status 8 (wstat 2048, 0x800)
DIED. FAILED tests 1, 3-9
Failed 8/9 tests, 11.11% okay
t/link_status…dubious
Test returned status 7 (wstat 1792, 0x700)
DIED. FAILED tests 1, 3-8
Failed 7/8 tests, 12.50% okay
t/links_ok…dubious
Test returned status 7 (wstat 1792, 0x700)
DIED. FAILED tests 1, 3-8
Failed 7/8 tests, 12.50% okay
DIED. FAILED tests 1, 3-8
Failed 7/8 tests, 12.50% okay
t/new…dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 1-7
Failed 7/7 tests, 0.00% okay
t/page_links_content…dubious
Test returned status 8 (wstat 2048, 0x800)
DIED. FAILED tests 1, 3-9
Failed 8/9 tests, 11.11% okay
t/page_links_ok…dubious
Test returned status 4 (wstat 1024, 0x400)
DIED. FAILED tests 1, 3-5
Failed 4/5 tests, 20.00% okay
t/pod-coverage…ok
t/pod…ok
t/stuff_inputs…dubious
Test returned status 2 (wstat 512, 0x200)
DIED. FAILED tests 1, 3
Failed 2/3 tests, 33.33% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
t/00load.t 1 256 1 1 100.00% 1
t/content_contains.t 4 1024 5 7 140.00% 1 3-5
t/content_lacks.t 4 1024 5 7 140.00% 1 3-5
t/follow_link_ok.t 5 1280 6 9 150.00% 1 3-6
t/get_ok-parms.t 255 65280 16 31 193.75% 1-16
t/get_ok.t 10 2560 11 19 172.73% 1 3-11
t/has_tag.t 6 1536 7 11 157.14% 1 3-7
t/link_content.t 8 2048 9 15 166.67% 1 3-9
t/link_status.t 7 1792 8 13 162.50% 1 3-8
t/links_ok.t 7 1792 8 13 162.50% 1 3-8
t/new.t 255 65280 7 13 185.71% 1-7
t/page_links_content.t 8 2048 9 15 166.67% 1 3-9
t/page_links_ok.t 4 1024 5 7 140.00% 1 3-5
t/stuff_inputs.t 2 512 3 3 100.00% 1 3
/usr/bin/make test – NOT OK
Running make install
/usr/bin/make test – NOT OK
Running make install
make test had returned bad status, won’t install without force

Up above it said about Test::More not installing. I tried to install
that just to get even more errors.

5

Up above it said about Test::More not installing. I tried to
install that just to get even more errors.

If you can’t get Test::More installed properly, then I wouldn’t be
surprised if you can’t get the test suite of the other modules to
work – Test::More is used pretty extensively in test suites these days.

–dave
Code Monkey, Best Practical Solutions
David Glasser | glasser@bestpractical.com

6

David Glasser wrote:

If you can’t get Test::More installed properly, then I wouldn’t be
surprised if you can’t get the test suite of the other modules to work
– Test::More is used pretty extensively in test suites these days.

Things go with a force, but then RT just acts strange with certain
things. For instance, RTFM and Asset Tracker load but don’t work properly.

I’m assuming this is an issue with the perl test suite. Thanks for
looking into it.

Max

7

Up above it said about Test::More not installing. I tried to
install that just to get even more errors.

If you can’t get Test::More installed properly, then I wouldn’t be
surprised if you can’t get the test suite of the other modules to
work – Test::More is used pretty extensively in test suites these days.

I’m having the same problem. I installed a 3.4.2 on Centos4 a
few weeks ago and upgraded to 3.4.3 without much trouble but
now I’m trying to do the same thing to have a test system
and WWW::Mechanize isn’t installing. It looks like the live
tests against google are returning 404 ‘page not found’ errors
instead of what the test expects to see.

…OK… I did a force install on WWW::Mechanize but still had
trouble with some other things. I think installing
Pod::Tests was what it needed to get pod2test. After
repeating the rt-test-dependencies --install a few more
times after that I think everything is there.

Les Mikesell
les@futuresource.com

8

Les Mikesell wrote:

…OK… I did a force install on WWW::Mechanize but still had
trouble with some other things. I think installing
Pod::Tests was what it needed to get pod2test. After
repeating the rt-test-dependencies --install a few more
times after that I think everything is there.

I know the mech dump utility was complaining about Test::Memory::Cycle
Test::Pods and Test::Warn, but it said they were optional. I installed
all three with the tests still failing. I’ll give Pod::Tests a try in
bit and see if it works the same as it did for you.

Max

9

David Glasser wrote:

If you can’t get Test::More installed properly, then I wouldn’t be
surprised if you can’t get the test suite of the other modules to work
– Test::More is used pretty extensively in test suites these days.

After much correspondence with another having the same issues as I was
with this post, we finally got it narrowed down to an offending
HTML::Mason issue. We ended up installing Pod::Tests first, force
installing WWW::Mechanize, and Test::More. Then I ended up installing
DBIx::SearchBuilder manually as well. After that, HTML::Mason version
1.28 was installed from tarball (It does not play well with 1.31).

This seemed to cure the issues with Asset Tracker and RTFM not showing
up in the menus. It also cured some other odd behavior RT was
exhibiting. I just wanted to post back about this issue in case others
could find it helpful.

Max

10

I don’t think I ever got WW::Mechanize to install without forcing it.
There always seems to be tests that fail.On Wed, 2005-09-07 at 11:22 -0400, Max wrote:

David Glasser wrote:

If you can’t get Test::More installed properly, then I wouldn’t be
surprised if you can’t get the test suite of the other modules to work
– Test::More is used pretty extensively in test suites these days.

After much correspondence with another having the same issues as I was
with this post, we finally got it narrowed down to an offending
HTML::Mason issue. We ended up installing Pod::Tests first, force
installing WWW::Mechanize, and Test::More. Then I ended up installing
DBIx::SearchBuilder manually as well. After that, HTML::Mason version
1.28 was installed from tarball (It does not play well with 1.31).

This seemed to cure the issues with Asset Tracker and RTFM not showing
up in the menus. It also cured some other odd behavior RT was
exhibiting. I just wanted to post back about this issue in case others
could find it helpful.

Max

The rt-users Archives

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Buy your copy of our new book, RT Essentials, today!

Download a free sample chapter from http://rtbook.bestpractical.com
Scott T. Hildreth shildret@scotth.emsphone.com

11

I don’t think I ever got WW::Mechanize to install without forcing it.
There always seems to be tests that fail.

Yes, I think they are testing for content from the internet that
is now different. The other problem was with pod2test now being
in the Pod::Tests package.

Les Mikesell
les@futuresource.com

12

If you can’t get Test::More installed properly, then I wouldn’t be
surprised if you can’t get the test suite of the other modules to work
– Test::More is used pretty extensively in test suites these days.

After much correspondence with another having the same issues as I was
with this post, we finally got it narrowed down to an offending
HTML::Mason issue. We ended up installing Pod::Tests first, force
installing WWW::Mechanize, and Test::More. Then I ended up installing
DBIx::SearchBuilder manually as well. After that, HTML::Mason version
1.28 was installed from tarball (It does not play well with 1.31).

This seemed to cure the issues with Asset Tracker and RTFM not showing
up in the menus. It also cured some other odd behavior RT was
exhibiting. I just wanted to post back about this issue in case others
could find it helpful.

RT 3.4.4 fixes the issue with Mason 1.31. For some reason I had
to reinstall everything from scratch to make AT and RTFM show
up again - but I didn’t try clearing the Mason data cache first.
(And note that the ‘make install’ step for AT clears any existing
database entries and it’s ‘patch’ step seems not to be needed with RT
3.4.4.).

Les Mikesell
les@futuresource.com

13

Les Mikesell wrote:

RT 3.4.4 fixes the issue with Mason 1.31.

Alright cool. I’ll have to give that try next test system. Have you had
any issues with upgrading from 3.4.3 to 3.4.4? Or haven’t you attempted
to try that yet?

Max

14

Les Mikesell wrote:

RT 3.4.4 fixes the issue with Mason 1.31.

Alright cool. I’ll have to give that try next test system. Have you had
any issues with upgrading from 3.4.3 to 3.4.4? Or haven’t you attempted
to try that yet?

When I just did an upgrade, AT/RTFM still did not show up. Removing
the files under /opt/rt3/var/mason_data/obj might have fixed it at
that point, but I removed all of /opt/rt3, re-installed everything
from the newest versions, then put back my old
/opt/rt3/etc/RT_SiteConfig.pm. The only quirk was that the ‘make
install’ step of asset tracker cleared the existing entries from
the database. It is a little confusing when the code and database
steps are tied together since I wanted to install new code but
keep the existing database. This was a test machine where I didn’t
really care about the entries but it might be a problem for someone
else. I haven’t looked yet at whether ‘make upgrade’ would have done
the right thing, but it probably does. If you do a mysqldump before
starting, you could always drop the old database back anyway.

Les Mikesell
les@futuresource.com

15

Les Mikesell wrote:

I haven’t looked yet at whether ‘make upgrade’ would have done
the right thing, but it probably does. If you do a mysqldump before
starting, you could always drop the old database back anyway.

True, same with Postgresql, you could just do a dump. I just did a quick
upgrade on my test box here, from 3.4.3 to 3.4.4, and AT wouldn’t load
up. I just did a ‘make upgrade’ for AT, a service httpd restart, and it
came back up. This was all with an empty database though. RTFM seemed
unaffected for me, it loaded up…again with an empty database though.

Max

16

Yes, according to the AT README file you should do a ‘make upgrade’,
not a ‘make install’.

-ToddOn Wed, Sep 07, 2005 at 12:49:14PM -0500, Les Mikesell wrote:

On Wed, 2005-09-07 at 11:57, Max wrote:

Les Mikesell wrote:

RT 3.4.4 fixes the issue with Mason 1.31.

Alright cool. I’ll have to give that try next test system. Have you had
any issues with upgrading from 3.4.3 to 3.4.4? Or haven’t you attempted
to try that yet?

When I just did an upgrade, AT/RTFM still did not show up. Removing
the files under /opt/rt3/var/mason_data/obj might have fixed it at
that point, but I removed all of /opt/rt3, re-installed everything
from the newest versions, then put back my old
/opt/rt3/etc/RT_SiteConfig.pm. The only quirk was that the ‘make
install’ step of asset tracker cleared the existing entries from
the database. It is a little confusing when the code and database
steps are tied together since I wanted to install new code but
keep the existing database. This was a test machine where I didn’t
really care about the entries but it might be a problem for someone
else. I haven’t looked yet at whether ‘make upgrade’ would have done
the right thing, but it probably does. If you do a mysqldump before
starting, you could always drop the old database back anyway.

–
Les Mikesell
les@futuresource.com

The rt-users Archives

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Buy your copy of our new book, RT Essentials, today!

Download a free sample chapter from http://rtbook.bestpractical.com

17

Yes, according to the AT README file you should do a ‘make upgrade’,
not a ‘make install’.

Maybe I missed something but I couldn’t see anything that distinguished
the code and database components in the README. I wanted a complete
new install of the code and had removed /opt/rt3 before starting
(because upgrade attempts had not gone well…). But, I wanted
to hook to the existing database when finished. I just thought I
should mention this in case someone does the same on a production
system. I think it would be more clear if there were separate
steps to install/upgrade the code and install/upgrade the database
since they may be out of sync in various ways as you upgrade or
move things. It would be even better if the database had a field
that tracked its current version and the install/upgrade script
automatically did whatever was needed for the current code version
to work.

And by the way - thanks for releasing asset tracker… I hate for
my only comments about free software to be complaints.

Les Mikesell
les@futuresource.com

18

Yes, according to the AT README file you should do a ‘make upgrade’,
not a ‘make install’.

Maybe I missed something but I couldn’t see anything that distinguished
the code and database components in the README. I wanted a complete
new install of the code and had removed /opt/rt3 before starting
(because upgrade attempts had not gone well…). But, I wanted
to hook to the existing database when finished. I just thought I
should mention this in case someone does the same on a production
system. I think it would be more clear if there were separate
steps to install/upgrade the code and install/upgrade the database
since they may be out of sync in various ways as you upgrade or
move things. It would be even better if the database had a field
that tracked its current version and the install/upgrade script
automatically did whatever was needed for the current code version
to work.

And by the way - thanks for releasing asset tracker… I hate for
my only comments about free software to be complaints.

The difference between an install and an upgrade is that an upgrade
doesn’t initialize the database. An install does. The README doesn’t
say so, but it is quite explicit about performing a backup before
you do anything. Not doing so would be foolish under any circumstances.
Prompting before removing the tables would be a good thing though.
Patches are always welcome.

-Todd