Best practice for releasing Perl modules to staging and live

Dave Cross dave at
Mon May 18 16:29:17 BST 2009

ian wrote:
> Paul Johnson wrote:
>> On Mon, May 18, 2009 at 02:22:09PM +0100, ian wrote:
>>> How best to ensure different environments have the same versions of 
>>> Perl  modules?
>>> Any other methods that should be considered?    
>> Pick a packaging system - preferably the one which is native to your OS.
>> Build your packages on your development system.  Only install packages 
>> on your test and prod systems.
> Are you advising to (re)build CPAN Perl modules this way, or are you 
> just describing what to do with our own Perl modules?

Surely these packages will already exist for (at least) the most popular 
modules on the most popular distributions.

For packages that already exist for your distribution of choice you have 
three options:

1/ Download them and install them from the standard repostories
2/ Copy the packages from the standard repositories into a local 
repository that your internal servers use
3/ Build your own versions of the modules

Option 3 sounds far too much like hard work for me :-/

There will, of course, be a (hopefully far smaller) set of modules that 
aren't already packaged for your distribution. Once you've built those 
packages, you could consider sharing them with the rest of the world.

> One company I worked at did just this for CPAN modules, but it was a 
> many-day exercise to work out all the dependencies of (for example) 
> Catalyst and to build them all into Debian packages.

Which is precisely why you should use the prior art from your 
distributions packaging team.


More information about the mailing list