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

[Les Mikesell]

On Wed, 2005-09-07 at 22:26, Timothy E Miller wrote:

> Well, I guess my email was more about how people (or event the RT
> developers) handle "this", where "this" is installing an identical,
> complete and (presumably) working RT service on different systems at
> different times.  In an RPM world, you simply build (ugh) all the
> Perl modules into RPMs and incorporate them into a kickstart
> process.

OK, but what do you expect to happen when your RPM based
distribution includes a conflicting updated RPM and
you want to do an update?  Or you've updated, then want
to install your bundle?

>   Viola!  You can clone (DB issues aside) a billion RT
> servers a year from now and know you have an identical setup.

But a year from now you'll want the updated versions not
a frozen set that probably have a lot of bugs we just
haven't found yet.

> My imaging setup is
> RPM based so this becomes a challenge but only because of the CPAN
> installation part (most of which is mitigated by cpan2rpm ... but
> only if you can build the 100 or so freakin' RPMs).

I think you have the right idea, but either the RPMs have to
get pushed into the main OS distribution at the start of
the project or they need to install as an RT library
in a place that is searched first and doesn't conflict
with anything the OS may or may not include.  If you
just want the ability to put back exactly what you had,
any number of tar/dump/rsync based backup programs can
do that. (I happen to like http://backuppc.sourceforge.net/).
However the real value of RPM packaging is that with
yum/up2date/apt-get/urpmi, etc., any number of systems
can stay current with updates made to a central
repository.  If you aren't planning for the update capability
it doesn't seem worth the extra effort to do rpm packaging
compared to a script that installs the CPAN tarballs and
saving a copy of the versions you want.

-- 
   Les Mikesell
     les at futuresource.com