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

[Timothy E Miller]

On Wed, 7 Sep 2005, Les Mikesell wrote:
> > And while I've got your attention, how does everyone else handle the
> > fact that there are ~100 perl modules from CPAN required for RT that
> > are randomly (almost chaotically) changing individually and in
> > almost certainly incompatible ways?
> >
> > I'm just trying to get a handle on it, that's all.
>
> It would be nice if those were all bundled into our favorite
> OS distributions.  However, if someone else packages them
> in a way that the system package manger understands there
> will be new conflicts if they are later included in the
> distribution.   I'm not sure there is an answer better than
> wading through the CPAN install problems as they happen.
>

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.  Viola!  You can clone (DB issues aside) a billion RT
servers a year from now and know you have an identical setup.

So, did they (RT devs), at one point in time, find the perfect mix
of modules, install them via CPAN and then build a CD iso of that
system in order to repeated clone that "perfect" set of modules?
Do the roll the dice with versions in CPAN everytime they install
RT?

My goal, if it isn't clear from above, is that I want to be able to
find some method of automatically provisioning a system to be an RT
server at any point in time and not worry about a new version of
Apache::Session or HTML::Forms or Digest::MD5 blowing the whole
thing up.  Primarily this is a disaster recovery goal (the DB is on
a DB server that, already, has DR capability).  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).

Comments and thoughts are greatly appreciated.
-Tim

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Timothy E. Miller, PhD, RHCE                   voice:   (336)758-3257
Systems Analyst Lead, High Performance Computing fax:   (336)758-7127
Wake Forest University                          cell:   (336)782-6987
Computer Science, Information Systems, Physics
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~