[rt-users] RT and the Perl Dependency Nightmare...

[Scott T. Hildreth]

On Fri, 2005-09-09 at 07:58 -0500, David J. Schnardthorst wrote:
> -----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:
> > On Thu, 2005-09-08 at 21:19, Timothy E Miller 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 at scotth.emsphone.com>