Slashdot Mirror

← Back to Stories (view on slashdot.org)

Autopackage Universal Package Manager

Posted by Zonk on from the i-love-packaging-managers dept.

nanday writes "I currently have an article on Linux.com about Autopackage. Autopackage is developing a universal package manager for the GNU/Linux desktop, separate from the package management for the system. It includes installation for individual users, a lot of concern for interface design and documentation, and some ideas about the future of package management that are sure to raise some debate." From the article: "Besides ... technical problems, the Autopackage team believes that managing system and desktop software together is a mistake. It requires developers to pay attention to desktop applications that are of secondary importance to them, and confuses end users with problems about dependencies and upgrades." Linux.com is a sister site to Slashdot. (say that three times fast)

3 of 73 comments (clear)

  1. Not exactly loved by the distro people... by keesh · · Score: 5, Informative

    Autopackage is not exactly loved by the distro people. See commentary from Gentoo, Debian, more Debian... Might be wise to keep those remarks in mind when considering using Autopackage packages on a distribution...

  2. Re:Great Idea by Arandir · · Score: 4, Insightful

    "Native package managers' dependency detection depends on a database. Autopackage, on the other hand-detects dependencies by actually scanning for them."

    Such a simple idea, such an absurdly simple idea. Yet it's one that 9 out of 10 distros just can't manage to get right. Building one library yourself should NOT break your entire package management system. A minor bugfix release to a library where no ABI has changed should NOT necessitate an update to every application that uses it.

    --
    A Government Is a Body of People, Usually Notably Ungoverned
  3. Haven't we debunked this before? by dondelelcaro · · Score: 4, Interesting
    By default, programs installed with root privileges are placed in /usr/share.
    I sure hope that's a typo for /usr/sbin... If not, well, that's so horribly broken that I don't even want to get strarted with it. FHS anyone?
    When a package is removed, its dependencies remain. Hearn and Lai point out that dependencies are not always removed by some other package management systems, either.
    Some package management systems may not do that, but at least they keep track of exactly which packages have been installed so you at least have a chance of removing the dependencies at some point in time. With this solution you end up with files on your system that have no clear correspondence to any package, which kind of defeats the purpose of having a package in the first place. (To just expose my bias... aptitude, synaptic or deborphan anyone?)
    "A binary from one distribution doesn't always work on another, because of things like glibc symbols and C++ ABI." [...] "Native package managers' dependency detection depends on a database. Autopackage, on the other hand-detects dependencies by actually scanning for them."
    Right, and what exactly is autopackage going to do about these dependencies once it has found that they don't match up? Use LD_PRELOAD and have multiple copies of system libraries in place instead? Oh wait, autopackage is for "desktop packages only".

    Of course, all of that isn't to say that autopackage may not do something useful in the future, but it sure looks like some of the fundamental problems of developing and distributing packages which other packaging systems have already dealt with still remain to be solved.

    In any case, if you don't believe me, see what Scott Remnant has had to say on the matter (he's currently the dpkg maintainer, so he at least is passingly familiar with the issues surrounding a packaging format.)
    --
    http://www.donarmstrong.com