[Dbix-class] Module versioning

[Nigel Metheringham]

Just to follow up with my experience/practice...

We use Centos 5.x (still some 4.x in production for a couple of
longer term products - they will migrate onto 6.x in the
foreseeable future).

In the past we have tended to build applications as rpms, and
modules as individual rpms - normally using cpanspec from the
Fedora project to handle packaging (this does 95% of rpms without
any manual work). The perl I used was platform standard but rebuilt
with a couple of smallish patches (which I think are now
mainstream).

I finally got fed up of sitting on perl 5.8.8.

I now build one perl-support rpm, which contains perl (5.12.3
currently) and several hundred other modules needed (I have one
Task module that pulls in the entire set I need). The modules come
from a git versioned mini-cpan snapshot of CPAN. Building the rpm
takes a couple of hours. The rpm build process uses perlbrew to
build a perl under /opt/perl - the system perl is left untouched
(so path lines are rather vital).

The time to build a new perl-support module when needed, even with
a couple of iterations of a few hour build time, is much much less
than the time taken to update the module rpms - and the build and
update process is largely automated so its not like individual
module updates which tended to need a load of fiddling.

Applications are tested against this big lump of support package,
and then both applications and the support package are deployed as
rpms.

Hope that helps - its still pretty new to us, with one application
fully on this system and one minor one also using it. The other few
apps under maintenance are likely to transition shortly.

	Nigel.


--
[ Nigel Metheringham ------------------------------ nigel at dotdot.it ]
[                 Ellipsis Intangible Technologies                  ]