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

[Timothy E Miller]

All right, since everyone is blowing this way out of proportion, I
guess I should respond ... in like outrageous fashion.

[RT-Perl modules below refers to Perl modules from CPAN req'd by RT]

Les, "what do I do when Red Hat upgrades Perl?"  Answer NOTHING!
That's the whole point of the Enterprise product line, security and
bug fixes ONLY.  NO NEW FEATURES.  In principle (and sure it's a bit
naive), nothing breaks except the "bugs" (i.e. the bugs don't work
any more so they're "broken"...get it? Ha, ha! :)

As I'm a realist, some RT-Perl modules might not work OR more
realistically, some of the RT-Perl modules/RPMS overwrote what Red
Hat shipped.  Answer again is simple, reinstall my RT Perl RPMS on
top of it.

The whole point is *NOT* some beautiful, static, utopian situation.
The point is MAINTAINABILITY and REPRODUCIBILITY.  If I upgrade Perl
and something breaks, Hmmm... maybe it was the Perl upgrade.  If I
decide to upgrade the DBIx::SearchBuilder module and something
breaks, then maybe it was the upgrade.

If I take and provision a second webserver to deploy RT on (so I can
shutdown the primary and do maintenance on it), it'd be nice to know
I'll have a working RT on it.  Other's prior knee jerk "just rsync
it" or "restore from backup" completely missed my statement of being
RPM based (especially in the imaging side).

With the current RT installation method, so much **** changes in
Perl CPAN land from version to version that I have to spend a whole
week trying to debug when to ignore this failed test or which
packages I have to force.  And since I don't do regular (read:
religious) upgrades of RT from minor-sub-release to minor-sub-release,
I then have to jump from 3.2.x to 3.4.4 with a whole new slew of
package dependencies.  Remember, I'm a sysadmin... not an RT admin.

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.

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.  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.

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 was just soliciting folks for more production ready methods that
they may have used or developed rather than the current old school
manual hack currently in place.

-Tim

P.S. Of course, if I had $2k, I imagine the first thing I'd get from
BestPractical is a CD with all the Perl modules with the correct
software versioning and dependencies taken care of.

On Wed, 7 Sep 2005, Les Mikesell wrote:
> 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.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~