-=| Gabor Szabo, 31.01.2012 14:48:47 +0200 |=- > On Tue, Jan 31, 2012 at 12:39 PM, Damyan Ivanov <dmn@debian.org> wrote: > >> 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. > > That sounds good in theory but cannot be always followed. > There are limited resources any given time. One cannot re-test > every application, every time and, especially with older applications, > test coverage might be very low. > > That means any unnecessary change is an unnecessary risk. > [1] "If it works, don't touch it" :) It is a mater of priorities. One can either spend time writing tests, or spend time monitoring used modules for bugs/vulnerabilities and extracting patches. There's also the third option -- hope for the best and not care until a problem is proven to exist. > > 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. > > Running Debian/unstable on a production machine sounds very risky. > If I understand, that means a lot of things are unstable > and I constantly need to upgrade. Even the kernel. > Which means frequent reboots as well. Right? I develop on unstable and deploy on stable. Using selected set of packages from unstable or testing is rather easy, but these are exceptions. Debian has a very big collection of CPAN distributions packaged :)
Attachment:
signature.asc
Description: Digital signature