[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "Avoiding the vendor perl fad diet"

-=| Gabor Szabo, 31.01.2012 08:59:04 +0200 |=-
> If I am not mistaken the @INC order was not really "correct" prior 
> to (hmm, I thin 5.12 but I am not sure) but recently it has been 
> fixed and now site comes before vendor so this *should* not be an 
> issue.

I think @INC ordering is part of the Debian Perl policy[1] and I can't 
remember that changed recently.

    [1] http://www.debian.org/doc/packaging-manuals/perl-policy/ch-perl.html#s-paths

> Still I hear - though never actually checked - that some modules 
> still install themselves in other places and not in "site".

Bugs are everywhere. Please report them :)

> So I recently thought how to solve this.
> One solution could be to use separate local::lib directories for each
> application. That would include some duplicate module installations
> but that would reduce the risk.

You seem to have re-invented the Ruby gems hell :)

Bundling your application with the versions you know are working is 
bad. You sacrifice security upgrades and bug-fixes that somebody else 
does for you. And, sooner or later you will have to upgrade. Better 
make that part of the whole process than some extraordinary event.

Better spend resources making sure any upgrades are harmless, probably 
by having a test environment, or always using the latest version when 
developing (so that you can catch any problems early). Any 
incompatibility is either a bug and should be fixed, or applications 
should be adapted.

Here's my recipe for deploying Perl applications:

 * ensure every dependency is packaged for Debian. If not, package it 
   (this was why I joined the Debian Perl group :)
 * develop with current versions from Debian/unstable
 * deploy application as a Debian package, with proper dependencies
 * profit

Works very nice even for applications that have only one instance in 
production and is a killer for multi-instance deployments.

Attachment: signature.asc
Description: Digital signature

Reply to: