Linked by Amjith Ramanujam on Tue 23rd Dec 2008 00:30 UTC
Linux 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.
Thread beginning with comment 341155
To read all comments associated with this story, please click here.
A solution to the wrong problem
by darknexus on Tue 23rd Dec 2008 02:00 UTC
darknexus
Member since:
2008-07-15

Solving dependency hell would have been nice several years ago. These days, it is rarely a problem unless you're using the unstable repo of whatever distro, and if you do that it comes with the territory on occasion.
Packaging isn't really the issue. Binary compatibility is. What good would it do to have a distribution-independent package manager, if my software is going to need recompiled to fit each distribution anyway? Before we can have distribution-independent packages--before we even worry about that--there has to be a way for those binaries to run in a distribution-independent fashion. At the moment, this is not the case, particularly though not exclusively regarding GUI applications.
Once this is achieved, then having distro-independent packages is a must. Until then, this is a solution in search of a nonexistent problem.

sbergman27 Member since:
2005-07-24

Before we can have distribution-independent packages--before we even worry about that--there has to be a way for those binaries to run in a distribution-independent fashion.

Great! Let's get to work. What are some examples of binaries running on one distro, but not on a contemporary one?

Reply Parent Bookmark Score: 6

g2devi Member since:
2005-07-09

Many reasons. Among which:
* Different GCC versions
* Different GCC compilation options
* Incompatible library APIs
* Incompatible file formats
* Dependence on kernel functionality no longer supported
* Dependence on kernel functionality specially compiled for a distro
* Dependence on specific distro-specific directory structures
* Dependence on specific distro-specific packages that no-one else supports

Reply Parent Bookmark Score: 8

christianhgross Member since:
2005-11-15

VMWare...

Hey worse yet, if I upgrade the kernel then VMWare breaks....

Yet on Windows NO PROBLEM...

When I look at how to install VMWare server on Linux, and then on Windows I think, "yupe this is the reason why desktop Linux will NEVER pickup..."

Reply Parent Bookmark Score: 1

orestes Member since:
2005-07-06

The simple solution, at least from an interested 3rd party distributors standpoint, would be to do statically linked binaries all living in their own neat little world under /opt or somesuch.

Reply Parent Bookmark Score: 5

AdamW Member since:
2005-07-06

Right, and you package what like that?

All 'applications'? How do you define an app? What if it comes with a library? A library that's used by other apps?

How do you package KDE or GNOME? Half as little lumps in /opt, half with a different package system in /usr? Sounds fun. How do you package GTK+? How about X, how's that get done? Again, do you split it up like KDE or GNOME?

I really wish people who haven't the first freaking clue how to build a distribution would stop thinking they have the obvious ultimate answer to package management. There isn't one.

Reply Parent Bookmark Score: 3