La "Autopackage" projekto promesas pli facila instalilon por programoj, sed ĝi kauzas pli multaj da problemoj ol ĝi solvis.
Well, there’s plenty to like. The goal is certainly laudable; it is too difficult to get software installed that your distro vendor doesn’t support. Furthermore, the Autopackage team have wisely chosen not to fight the distros; they emphasize that their system is a complement, not a replacement, for the distro’s package manager. The file structure doesn’t look too bad. They seem to at least have a clue about security, even if their current security story isn’t all that great.
Unfortunately, they’ve yielded to the temptation towards short-term fixes. As a consequence of at least one short-term fix, I predict that distro vendors are going to start seeing support requests from Autopackage users tht may, in some cases, be tough to fix. Were I responsible for supporting a Linux distro, I would tell my users that use of Autopackage breaks the support contract, or (alternately) that such support would cost extra.
What’s the problem? The big one: Autopackage installs to /usr, according to a comment by someone involved with the project. If something is installed by Autopackage, and later that same thing is shipped by Debian, the two packages will barf all over each other, causing both packages to fail (despite their unsubstantiated claim otherwise). Telling users to just avoid the Debian package won’t work, because package dependencies change over time, and any popular package stands a very good chance of being added to a meta-package eventually. The same thing is likely just as true for Red Hat, Mandrake, and the like, though obviously the details may differ.
It’s particularly interesting that the software allows the option to install to other places, such as $HOME, /usr/local, and so on. Supposedly, /usr is supported because:
…there are many broken distributions that don’t setup paths for /usr/local correctly.
Yet, in their FAQ, they talk about cooperating with the various distributions to create something like a “Desktop LSB” for handling library dependencies that their tool isn’t good at handling yet. Of course, getting the distros to support /usr/local properly is a much easier task than getting the distros to agree to and implement a new standard. Why blow off the easy thing, and assume the hard thing?
This isn’t the only problem, but it is the biggest one. The other problems are probably easier to fix, especially if they keep their promise for full package-manager integration in the next version. I’m curious how they handle the conflicting library problem, or newer libraries with new symbols that don’t require soname upgrades, but I’m sure they’ve had to deal with those problems to get this far.
Ultimately, I think the Autopackage people would do well to include some traditional distro people in the conversation, and work to integrate well within the parameters the distros set. As they already acknowledge, they aren’t going to get anywhere without some buy-in from the distros. What I wonder about is why they didn’t get that buy-in from the beginning, or if they did, why they aren’t talking more about it.
UPDATE: Joey Hess takes a closer look at the technology; to say he doesn’t like it is an understatement. And Mike from Autopackage responds in the comments to both of us (sorta).
UPDATE (2005-03-31): After a little heat and a little light in the comments, Adam Williamson of Mandrake is bringing the issue up on the Cooker list. His initial message is also posted in our comments, and you should be able to read the full thread here.
This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.