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

[Les Mikesell]

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.

-- 
  Les Mikesell
    les at futuresource.com