-=| 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 and I can't remember that changed recently.  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.
Description: Digital signature