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)

10 of 73 comments (clear)

  1. Great Idea by nbSouthPaw · · Score: 2, Interesting

    As someone who is new to linux this is the one area I struggle with. While not difficult installation of software on linux is quite different even among the different distributions. The autopackage software could make desktop solutions quite a bit easier for those of us that dont want to mess with system software very much but would like more control over desktop software.

    1. 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
    2. Re:Great Idea by /ASCII · · Score: 2, Informative

      I don't know enough about the package databases to know if there is a simple way around your first problem, but the second one is only a trouble in cases of lazy packagers making bad dependancy specifications. Package dependancies should be to the relevant ABI version of the library, which is usually stable across minor version numbers.

      --
      Try out fish, the friendly interactive shell.
  2. 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...

    1. Re:Not exactly loved by the distro people... by FooBarWidget · · Score: 3, Informative

      They don't like us because they want to centralize software packaging. Don't just blindly assume we're evil just because they're critical to us. Read what they write. For example:

      "To even unpack the package, you must run arbitrary code supplied by an untrusted source."
      Untrusted source? Is the upstream developer an untrusted source? If he cannot be trusted, then why would one trust third party Gentoo packages?

      "They install directly to the live filesystem."
      We have this little feature called "installing to $HOME". It won't touch /usr if you don't want it to. How hard is that?

      "They do not support configuration protection."
      We backup stuff if they're being overwritten.

      "They can clobber arbitrary files on uninstall."
      No proof. Bug reports please, because we sure haven't received any from our users.

      "The entire format is completely unportable and highly tied to x86 Linux systems."
      The reason why that is so is because none of the developers have anything but x86 systems. It's a bit hard to support PPC if we don't have such a machine, right? We already have some stuff in place to make sure x86 packages aren't executed on other architectures.
      But that aside: let us go back to the original problem: software installation isn't easy enough for the average user. And what architecture does 99% the average user use? x86! Now there's the main reason why we focus on x86: because that's where our target group are! The software installation problem is pretty much unique to x86 Linux.
      Non-x86 architectures are usually servers, not desktops. They don't need autopackage, so why should we worry about them? PPC users most likely use MacOS instead of Linux, so there's not much point in supporting that either.

      As for joey's blog: the only thing he's complaining about is that at the moment you cannot programmatically extract files from a .package. Average users don't even care about that! They just want the damn software to be installed and to work!

      Yeah I haven't replied to everything but you get the point.

    2. Re:Not exactly loved by the distro people... by Nevyn · · Score: 3, Insightful
      They don't like us because they want to centralize software packaging.

      Nobody wants that, but it's basically required. You can't solve the "I need to install mod_foobar, which requires Apache-httpd-2.2.0" problem without understanding what Apache-httpd is and what version you have, and how you get from here to there ... which requires a single way to query all software. This doesn't mean it can't be distributed, like DNS, just that you can't pretend you can have two roots and everything will be fine (or even blame those nasty root server operators for telling you otherwise when you try).

      Untrusted source? Is the upstream developer an untrusted source? If he cannot be trusted, then why would one trust third party Gentoo packages?

      Say you're installing a GNOME theme, it's basically just XML+pngs ... then assuming the installer is secure, there is no reason you can't just install this "package" from anywhere and try it out. The same is true with installing backgrounds, or documentation etc. (think CIA. world factbook).

      With aribtrary binary applications this is somewhat muddier, but there is still a deliniation between trusting the package and trusting the package installer (the later of which likely needs more privilages).

      For instance "conary" is one of the newer package management ideas, and to them packages are basically just collections of files which are tagged (Ie. doc/bin/shared-library). Installing/removing a package has basically zero security concerns.

      --
      ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
    3. Re:Not exactly loved by the distro people... by Nevyn · · Score: 2, Insightful
      The problem is that, unless you make a distinction between system and desktop, the user will be presented with a huge list with thousands of packages. If my dad wants to upgrade mune he really isn't interested in seeing glibc and qt in that list. It's more a user interface problem.

      And you still have to solve this problem when I distribute an epoll using application to a system using a glibc that doesn't have the epoll symbol. And this is such an obvious UI issue, I dearly hope you have a better example than this for why you screwed the pooch.

      If X requires Y, you can't just pretend otherwise and say "not our problem we just do desktop apps".

      The plugins should be upgradable too. But what prevents you from doing that?

      It's the same problem, you have X provided by you and Y provided by the distribution ... you can either: 1) hope version of Y is compatible. 2) upgrade Y when required. 3) always provide your own version of Y.

      Only option 2 works, and autopackage seems to think that not doing option 2 but a mixture of 1 and 3 is a feature. Back in the real world bugs aren't features.

      --
      ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
    4. Re:Not exactly loved by the distro people... by FooBarWidget · · Score: 2, Interesting
      "With aribtrary binary applications this is somewhat muddier, but there is still a deliniation between trusting the package and trusting the package installer (the later of which likely needs more privilages)."


      Not so with autopackage. You can run autopackages as user and install to ~/.local. You don't have to give it root access if you don't want to. And as autopackage is open source, you can check the source code for trojans. Autopackages are tarballs with a shell script header. Anyone can check the shell scripts for trojans.

      "For instance "conary" is one of the newer package management ideas, and to them packages are basically just collections of files which are tagged (Ie. doc/bin/shared-library). Installing/removing a package has basically zero security concerns."


      I'm not familiar with Conary, but do they take care of desktop integration stuff like menu items and icons? What about things like updating the icon cache? (If you don't do that some icons won't appear in the GNOME menu) Or the MIME cache?

      And does Conary research inter-distribution binary compatibility? As far as I know we are the only group that have good knowledge about binary compatibility problems and actively try to solve them. Without a solution for binary compatibility problems, you cannot make inter-distribution packages no matter what packaging system you use.
  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
  4. Yes, but... by hackwrench · · Score: 2, Funny

    ...will it be ported to Windows?