"We have developed a new package-management tool, called Opium, that improves on current tools in two ways: Opium is complete, in that if there is a solution, Opium is guaranteed to find it, and Opium can optimize a user-provided objective function, which could for example state that smaller
packages should be preferred over larger ones. We performed a comparative study of our tool against Debian's apt-get on 600 traces of real-world package installations. We show that Opium runs fast enough to be usable,
and that its completeness and optimality guarantees provide
concrete benefits to end users."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2007-06-04
Exactly! Trying to correct the actual problem instead of trying to be more complex in order to alleviate the already complex nature of something. The version system and model is a rough-spot to my untrained eye.
There are many different problems in any system. I don't disagree that there are serious complexities and difficulties in the packaging system, and in particular in creating and testing packages. I'm afraid we can't solve all the world's problems in one go, though: the OPIUM paper addresses three clearly identified (and demonstrated) problems; it doesn't preclude you or anyone else from tackling the others (see the comments on Zero Install and my responses: all this work is good and productive!).
IOW - if something requires libfoo4 and you have stuff that requires libfoo3 then libfoo4 SHOULD be all that is required and should automatically register as libfoo4 but also inform the package manager that libfoo3 is also satisfied. Of course, that isn't always possible depending on changes but often it IS possible to use a newer library for something that thinks it needs a older one.
You're describing a packaging problem. If X depends on libfoo it has a couple of choices:
1) Depends: libfoo == 3
2) Depends: libfoo
3) Depends: libfoo > 3
Either of the last two will work when installing X on a system with libfoo3. The first should only be used if X is known to only work with version 3 of libfoo. If something declares it explicitly needs libfoo version 3 when in fact it doesn't there is *nothing* that APT or OPIUM or any other package installation algorithm can do to fix it. We have to be able to rely on the rules the packages lay down because they're all we have to go on: imagine if in a real world system we said "Oh, it says it needs libc6 v.2.2, but we're going to upgrade to 2.3 because we think everything will be OK". You'd have a lot of broken systems and a lot of angry people.
Member since:2006-06-19
Yawn....yes please explain to me how I do not understand anything....again....
Yes, a packaging problem that is at the root of a lot of dependency issues/conflicts that require a package manager to be smart and try and resolve all the issues that occur.
I am saying what if you COULD ensure that newer versions (at least point or sub-point releases) of libfoo provided for old version requirements as well. No more conflict of having libfoo1.2.9 and some older app needing libfoo1.2.2 because the package manager KNEW that 1.2.9 provides 1.2.2 so the package manager creates a symlink for 1.2.2 to 1.2.9 for the older app that needs 1.2.2
Not that this is probable for various reasons but only that it is possible and would alleviate some issues at the CORE of the issue.
Member since:
2006-06-19
The solution isn't a better solver (although that's nice to have anyway), the solution is remove the possibility of conflicts.
Why do I need to use a massively complex algorithm to find the single version of some libfoo that works with all of the one thousand packages on my machine? What the system needs is a bit of slack. If there's a period of a few months when one program needs libfoo > 3 and another needs libfoo == 3 that shouldn't matter. Just keep two copies of libfoo on my system until the problem is fixed.
Exactly! Trying to correct the actual problem instead of trying to be more complex in order to alleviate the already complex nature of something. The version system and model is a rough-spot to my untrained eye.
That is along a similar line of thought that I TRIED to discuss with Chris at the forums. Not that I have used 0install or anything but that the development model version system needs to be standardized or some slack put into it to allow some flex and maintain some backward/forward compatibility/flexibility.If we could assure that packageB1.2.x would work with the handful of packages that rely on packageB instead of requiring packageB1.2.8 or > then that IMO would alleviate a lot of the dependency issues and conflicts.
IOW - if something requires libfoo4 and you have stuff that requires libfoo3 then libfoo4 SHOULD be all that is required and should automatically register as libfoo4 but also inform the package manager that libfoo3 is also satisfied. Of course, that isn't always possible depending on changes but often it IS possible to use a newer library for something that thinks it needs a older one.
Heck, how many of us hasn't symlinked a mis-match version and it worked fine or simply went in and fudged the requirements listed in a deb?
But I am not a big fan of standardizing anything either...
I am just not sure that apt has as many failures and problems as this study makes it out to have.
Edited 2007-06-04 19:41