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
On Mon, Feb 08, 2010 at 10:01:24AM +, 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
On Feb 13, 2010, at 9:30, Nicholas Clark wrote:
[Checking binaries into VCS]
This system likely *wouldn't* scale if we needed even a second architecture.
We have a git submodule for cpan/. We primarily deploy and develop on x86_64
linux, but we also keep the darwin/OS X arch updated so we
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
On 8 Feb 2010, at 10:01, Bruce Richardson wrote:
[...]
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
On Thu, Feb 04, 2010 at 06:17:51PM +, Dave Webb wrote:
Hi,
On 04/02/10 17:46, Paulo Edgar Castro wrote:
Long story short as I think I'm making a bit of a mess with the question...
We want to install all the 148 modules with the exact version number of
what we currently have installed.
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.
Dear mongers,
I come to you in the hope of enlightenment
At the place were I work we a have a perl software suite that depends on
roughly 148 modules not counting of course on the dependencies that
these 148 modules have.
Ignoring the fact that we currently have a perl binary which has
On 4 Feb 2010, at 18:04, Matt Sergeant wrote:
Paulo Edgar Castro wrote:
It's very likely that I might be missing some obvious knowledge/tricks here.
Would there be a cleverer way to accomplish this ?
Use your OS's package management system.
Which is pretty much guaranteed to not have the
On Thu, Feb 04, 2010 at 05:46:46PM +, Paulo Edgar Castro wrote:
Our initial thought was to just run through the motions of the app
Makefile which has defined these 148 modules with perl Makefile.PL
--defaultdeps make
and wait for the modules to install.
Then the penny droped and we
Hi,
On 04/02/10 17:46, Paulo Edgar Castro wrote:
Long story short as I think I'm making a bit of a mess with the question...
We want to install all the 148 modules with the exact version number of
what we currently have installed. Preferably we want to install
everything exactly as we have.
Look at shipwrite (on CPAN) also run your own CPAN mirror (see
CPAN::Mini) and don't forget version control of everything
Oh local::lib is also useful
On 4 Feb 2010, at 17:46, Paulo Edgar Castro
pauloedgarcas...@gmail.com wrote:
Dear mongers,
I come to you in the hope of
Ash Berlin wrote:
Use your OS's package management system.
Which is pretty much guaranteed to not have the exact versions they currently
have installed if they've been using `cpan` et al. to install it .
I don't mean get them from the OS distributor. I mean build RPMs (or
debs or
13 matches
Mail list logo
