Mathijs Kwik wrote:
As a developer in 3 languages (ruby & java professionally, haskell as hobby) I must say I really prefer just managing this manually, separate from the package manager.
I'm running ubuntu LTS (8.04) on production servers.
But this would mean that an environment for a language would also be somewhat frozen for at least 2 years, which isn't very useful. When 10.04 gets out with ghc 6.12.1, it will still mean that's the only thing available until 2012, or I need to upgrade the entire OS every 6 months.
Not necessarily. I am faced with a similar problem, having over 700 production client machines (administered remotely) in the field running the 8.04 LTS release. Because we use Debian packaging as the only sane way to manage binary distribution to that number of machines, we manage our own repository which is basically a validated version of 8.04, plus validated backports, plus our own packages. Furthermore, all of our own packages are built on an autobuilder to ensure that what is in revision control will actually build from source. The autobuilders all start off with a nearly bare install in a chroot, then install the build dependencies and finally build the package. In order for this to work for our one haskell package, I backported ghc-6.10.4 and a bunch of haskell libraries from Debian Testing so that this one package can be built in the autobuilder. I have also been hearing rumours that the next LTS release 10.04 will be more of a rolling release, where more recent versions of things will be available by enabling backports. <snip>
This might not be a solution for you, it really depends on your needs, but for me, I found it's often useful to control the exact environment an application needs and it gives developers the freedom to run whatever OS they like, which is a huge benefit if you use contractors or if devs want to work from home.
I think I found a solution with the same goals as your's, but with a different implementation. Since your machine count is smaller than mine, your scheme probably works better for your situation. For my larger machine count, I would not be happy to trade my scheme for yours :-). Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/