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]
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?