A next-generation package manager called Nix provides a simple distribution-independent method for deploying a binary or source package on different flavours of Linux, including Ubuntu, Debian, SUSE, Fedora, and Red Hat. Even better, Nix does not interfere with existing package managers. Unlike existing package managers, Nix allows different versions of software to live side by side, and permits sane rollbacks of software upgrades.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-06
"Because Linux distributions and the LSB do not define a suitably complete baseline, so application developers do not have enough information to know exactly which libraries they can expect to be provided already on any reasonable distribution."
Sure, but how are you going to get that to happen?
Boost is a good example, again.
Boost 1.37 just came out not long ago. Fedora's development branch upgraded to it (in a tag, I know, blah blah blah, it's just mechanics) almost immediately. Mandriva's just went the other day. That's because we're pretty bleeding edge distros and we like to have the latest version of everything. This means that around April-May, Mandriva and Fedora stable will have Boost 1.37.
Debian, of course, didn't go yet. Heck, sid is still on 1.34, which is now *two* majors out of date (there was a 1.36 before 1.34). This is because Debian is big and stable and bureaucratic and won't go until they're damn sure everything in their repos builds against the new major, on all platforms. This means there's not a chance in hell a stable release of Debian will have 1.37 for at least, oh, a couple of years, I'd say.
All the other distros are somewhere in between.
How do you plan to reconcile this? The reasons different distros contain different versions of things are fundamental to the nature of differences between distributions, not some kind of historical quirk. You can't get all distributions to just 'agree', because it would involve many distributions changing into something they aren't.
Yes, you could always include different majors of every library in the base. No, that's not really going to be sustainable for the long term, and how do you handle something that can't be libified - like, oh, say, HAL? Or Tcl?
Edited 2008-12-23 18:40 UTC
Member since:2005-07-06
If Boost is breaking it's API with every release and not bumping the major DSO version then the Boost developers need to learn how to manage an ABI. Although this isn't just Boost: it seems to be a fairly common issue with a lot of Open Source developers.
I never said getting everyone to agree on the baseline would be easy, but it's what needs to happen, and it's what the LSB is supposed to cover.
With your specific example (Boost) I'd suggest the only sane answer is to define a single version that must be available, and then allow distributions to ship newer versions in addition if they wish. That way the distros can relink all their system packages against the bleeding edge, but a third party developer can link against the baseline version.
Edited 2008-12-23 20:47 UTC
Member since:
2005-07-06
Why isn't static linking libawesome a solution?
Because Linux distributions and the LSB do not define a suitably complete baseline, so application developers do not have enough information to know exactly which libraries they can expect to be provided already on any reasonable distribution.
If the LSB defined libawesome as a "standard" library that would be provided as a DSO, and defined a baseline version, then I can dynamically link my application to use that version of libawesome (If I use a newer version, that's my problem). If it isn't in the baseline then statically linking it would be a perfectly acceptable solution which would eliminate the run-time dependency handling.
The obvious rebuttal is always "What if libawesome has a security issue? Now you have to upgrade every application that has linked libawesome!". The answer is that if the library in question is popular enough to be used by a large number of applications it should probably be in the LSB baseline, and if it isn't then you only need to upgrade a handful of applications anyway and your package manager is perfectly capable of doing that automatically for you.