Slashdot Mirror


Autopackage Universal Package Manager

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...

    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: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.