-=| 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