RT and the Perl Dependency Nightmare

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My two cents (if its worth that much). When I installed RT I isolated it to
have its own version of perl so that everything was contained in /opt/rt. This
makes life easier when you do need to pick up and move to another system.

I am in the process of writing a SPEC file (in my spare time) that will create
an RPM of rt and rt-perl. This will allow me to do an installation via RPM to
any system, easily. I may further create an RPM for RTIR and RTFM in the future
as I am using both. I’ll post the SPEC on the WIKI once I have a good working copy.

…or one could use PAR.

Les Mikesell wrote:

I can not (and will not) believe the RT developers at Best Practical
operate that way. Trusting that 20+ independent Perl developers
make only perfect bug-fixing upgrades (synchronized, no less) that
still all magically interoperate as they previously did without
breaking is only for children who believe in Santa Claus and people
who think the govt is here to help you.

Some people believe that published interfaces are not supposed
to change. It does take a certain amount of faith to maintain that
belief…

There is no way someone who does this for a living does not have a
set of Perl modules squirreled away for which they test incremental
development. Maybe RT devs don’t.

Well, yes, everyone who has built a working RT has a copy of
the working modules squirreled away in their .cpan/sources
and .cpan/build caches whether they know it or not. And
yes, I’ve resorted to grabbing copies of them for another
machine now and then.

Maybe every now and then (say
for major releases), they just fire off a big “CPAN upgrade all my
modules to the latest version” command and then fix what is broken.
As an admin/developer, I don’t think so.

Realistically, I’d guess that most people build a new copy
on a different machine with the latest of everything instead
of lots of in-place updates - then move the database when
the new version works.

And maybe the answer is to take a build a completely separate Perl,
Apache, mod_perl, RT, and RT-Perl (RT req’d perl modules) directory
tree and just tar it up and RPM-ize it. I don’t know.

I did miss the point of the RPM-ize step. Is it really a win
to do this compared to a scripted install of the corresponding
(saved) CPAN tarballs or are you doing it to fit into a scheme you
are already using extensively for other parts of your system. It
just seems like more work to get exactly the same thing done
that a ‘perl Makefile.PL; make install’ would do anyway.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDIYb80I5vtVF88i0RAu+zAKD0n5rRKw5inK/lamNoEnVl6QlOrgCgiYRf
2ojCzwesXcwof2azq1OBoNE=
=m9Ii
-----END PGP SIGNATURE-----


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

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