2 depend or not 2 depend

Paulo Edgar Castro pauloedgarcastro at gmail.com
Wed Feb 17 00:42:46 GMT 2010

> Also, having your dependencies coming directly from version control, rather
> than via installed packages gives you a couple of advantages
> 1: It's possible to have more than one checkout of the dependencies at the
>     same time, and trivially swap between them
> 2: It's easy to bisect problems caused by bugs somewhere in the dependencies,
>     by using the version control system to binary search revisions in your
>     dependencies, without needing to go to the complexity of using the package
>     manager at each test point to re-re-re-re-install all the packages.
> At work we're deploying to exactly one architecture and OS, which allows us
> to actually check in an installed tree "/usr/local"-a-like into subversion.
> This might seem crazy, but it means that we don't have to use developer time
> figuring out how to convert arbitrary CPAN modules into well behaved packages
> for the OS packaging system. Instead we directly use the CPAN shell to install
> to our tree, then commit the differences.
> This system likely *wouldn't* scale if we needed even a second architecture.

We've been deploying exactly in the same manner as you seem to with all 
the limitations it has...

In trying to improve our process we decided to go the route of option a) 
which is to to create our own CPAN with cpansite and not CPAN::mini.
That way we can "control" the modules we're using and with cpansite we 
can enforce specific versions of modules.

In the meantime we are also considering taking it from there ( as the 
work is still being done ) and going the package manager route in this 
case RPM.
We're currently trialling building perl and installing everything in a 
specific location and then packaging everything up in a arch RPM, if 
there's time we might consider the costs/benefits of managing it on a 
module by module basis.

What's compelling about the package manager option is that you can 
define provides/requires in order to satisfy dependencies, that way, the 
{rpm,deb} won't install if there's a library missing or some other 
component you might require rather than someone in a dark room ticking 
boxes for what needs to be installed.

Thank you for all your comments,


More information about the london.pm mailing list