2 depend or not 2 depend

[Nicholas Clark]

On Mon, Feb 08, 2010 at 10:01:24AM +0000, Bruce Richardson wrote:
> On Sun, Feb 07, 2010 at 11:39:00PM -0500, Matt Sergeant wrote:
> > Nicholas Clark wrote:
> >> It does if you have a second machine to test on.
> >> It doesn't if you have a shared development server, and the installed packages
> >> are common to all developers.
> >
> > Then the owners of those boxes need to learn about xen. And fast.
> 
> Xen isn't necessarily the answer to that problem.  There are pros and
> cons to a shared development server but the constraints which might
> force a company to use one may well also make Xen impractical; if you
> have limited resources, Xen is often not the most efficient use of them.
> 
> A build system with good dependency management, on the other hand, will
> work on a shared build server, the developers own laptop and the sacred
> place where the official production builds are done.

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.

Nicholas Clark