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)

Comments

Re:Great Idea

[Arandir]

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

Re:Not exactly loved by the distro people...

[Nevyn]

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.

Re:Not exactly loved by the distro people...

[Nevyn]

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.