Via Slashdot, we learn of the advent of Autopackage, a project to make it easy to install third-party software onto Linux systems in a distribution-neutral fashion. What’s not to like?
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.
UPDATE (2005-04-02): Ubuntu takes up the question, starting with this message. A bug has been filed and dismissed in Ubuntu’s BTS as well.
Hey, nice to see you have comments enabled unlike Joey 🙂
So installing to /usr – yes, nobody likes it much but it’s either that or get a constant stream of bug reports from users on broken distros (and *every* distro seems to be broken in some way) along the lines of “My program won’t start”, “I don’t get any menu entries” or “my file associations have no icons” etc etc. Installing to /usr solves all of this.
You are right that our FAQ says there should be some desktop LSB, and some distro equivalent to freedesktop.org as well. If one day this happens and we get better standardisation around these sorts of areas, maybe we’ll start dropping these sort of hacks and start telling users on the minority of distros which get it wrong to upgrade or use something else. Right now that isn’t feasable I’m afraid.
Yes native PM integration is a feature everybody wants. Originally it was planned as a 1.0 “blocker” item but people wanted to use autopackage even without that, for instance people not on Debian. Constantly shifting meta-packages for random apps are far less of an issue on distros that don’t try to package everything. So we decided to go stable and add that stuff later.
I’m afraid RPM integration ranks as more important than dpkg integration though. So it may be some time before autopackage registers with Debian. Possibly it won’t happen at all unless somebody steps up to write the patch (whereas I’ll do RPM integration myself if need be).
Final point – there were attempts to work with distributions, partly on an informal level and partly through the LSB. Unfortunately this generally went nowhere. Most distribution developers did not see the value in 3rd party packaging, believing (wrongly imho) that it was possible for them to package everything anybody could ever want or need themselves. The LSB packaging metadata group dissolved, in private a Debian developer compared asking for package metadata standards to “asking for world peace”. Hopefully we can work more closely with distribution developers in future, but it was decided the project and model would need to gain credibility by proving itself first.
thanks -mike
Hmm. You have good points.
Still, it’s important to realize that you could get a bad rep early. Speaking from experience, users tend not to listen to reasons why things are a certain way if that certain way seems broken. And I can also tell you: distro people aren’t likely to give you the benefit of the doubt when handling the support requests, either.
One possible solution: if Autopackage were to be delivered on Debian, its maintainer could turn off installing to /usr, and work on fixing the bugs with /usr/local (or /opt, or whatever). By making integration the responsibility of each distro, you avoid having to do the work yourselves to fix them all. OTOH, that’s a solution that will work better with community-based distros (Debian, Gentoo) and less well with commercial distros (SuSE, Mandrake).
Not that I’m volunteering or anything. 🙂
I suppose I’m disappointed by the Debian person’s response. Debian does get around to packaging nearly everything eventually; the problem is with brand-new stuff you want to try out (and with commercial apps, as you point out). For example, I have Tomboy locally built for my systems, because I really like it. I’d definitely Autopackage it if I could, and if I felt comfortable with the tech.
BTW: I’d listen very closely to Joey Hess. There aren’t very many people in the world who know packaging better than him.
I suspect that what you really want is /opt, not /usr/local.
From http://www.pathname.com/fhs/2.2/fhs-3.12.html :
The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.
From http://www.pathname.com/fhs/2.2/fhs-4.9.html :
/opt is reserved for the installation of add-on application software packages.
(I realise this is the wrong blog, but in case Mike happens to look here again… *g*)
Yes, that would certainly be a solution. I’d also be happy to accept patches to special-case this behaviour for distros that do get it right. In summary the most common things broken about /usr/local are:
* /usr/local/bin not in the PATH by default (believe it or not this does happen)
* /usr/local/lib not in the /etc/ld.so.conf file
* /usr/local/share/applications not a MergedDir in XDG menus, or not included in vFolder menus, etc (Debian seems to use a mix of menu systems right now)
* /usr/local/lib/pkgconfig not in PKG_CONFIG_PATH by default, though this doesn’t affect binary packaging systems like autopackage
* XDG_DATA_DIRS not being set correctly
If all of these things were fixed for the major distros, eg so the bug report level would be low, I’d absolutely be willing to consider changing the defaults.
/opt is equally valid – it doesn’t really matter where the software goes IMHO as long as users get a good experience.
Joey Hess may well know packaging very well, but once I sifted through the bile his main point seemed to be that the ,package format could not be parsed by Alien. That’s by design: there are a few stable interfaces provided by the package format itself (as opposed to the API) like the metadata comments at the top and the -x (extract) and -d (debug) command line switches. To get the payload out of an autopackage you can use the -x switch. Yes, this involves running a shell script however it’s all “in the clear” and anybody can read it to prove to themselves it hasn’t been hax0red. Automatic payload extraction isn’t currently supported, but I’d be willing to make it easier for programs to “prise it open”. I don’t care about Alien per se, as we have enough fun just makings things work right when we can do whatever we want and the last thing I need is bug reports of the form “I converted foo.package to a deb with Alien and it didn’t work! Autopackage must suck”.
thanks -mike
As far as MDK is concerned, we’re ‘broken’ in most of the ways Mike listed. It’s been discussed before in the MDK development community (yes, despite being a ‘commercial’ distribution, we have one…). Personally I favour /usr/local/bin being on the default path at least, but describing the situation as ‘broken’ is a little loaded; it’s an intentional decision and not an oversight. Adding /usr/local/lib to the default ld.so.conf could very definitely cause problems, as it makes it even easier for people to break the distro by doing the wrong thing. I know *autopackage* doesn’t intend to package vital system components, but users who haven’t yet learned better are entirely capable of doing things like building GTK+ from source in order to get the new version of the GIMP working. Having /usr/local/lib in ld.so.conf by default is only going to make it easier for people to shoot themselves in the foot.
I agree that installing into /usr is fundamentally broken and, while working around problems in the *short* term, is only going to cause much, much larger problems in the long term. A very obvious concise set of instructions on how to configure the major distros to use /usr/local properly would make me a lot more inclined to like autopackage. As it is currently, I’m dreading the inevitable breakages it’s going to cause users once they’ve been using it a while.
—
Adam Williamson | Editor, Mandrakelinux Community Newsletter
AdamW wrote: “Adding /usr/local/lib to the default ld.so.conf could very definitely cause problems, as it makes it even easier for people to break the distro by doing the wrong thing. […] users who haven’t yet learned better are entirely capable of doing things like building GTK+ from source in order to get the new version of the GIMP working.”
Hm, that just causes people to ask for help elsewhere. In fact, you’ll waste not only your users time by that, you’ll waste also other peoples time, too — the time of the support people. Search at Linuxquestions.org for “gtk build source” for references. There are lots of people that tried to build from source althought they have no idea what GCC is, for example.
Installing a new release (and being able to talk about it with your friends) is one of the fun things about computers. It’s not the installation or the usage, it’s about being able to take part in conversations with your friends — even if your not a geek who’s able to do the ./configure && make && make install dance.
To know that your distro will deliver the next GIMP version in three month doesn’t help much, when you’d like to talk about its new features with other graphic artists now.
This is the problem with APT and all other systems: There’s no excitement about a release — in contrast to Windows, for example. Think also about journals: They can hardly pack a proper package for every software they discuss on a single CD. It makes no fun buying journals when you need to spend half an hour for translating their installation instructions to your own distribution for every story.
For these reasons, distros that target private users will hopefully see the benefit of having autopackage installed by default, and properly configured.
clausi – I am (unofficially) a support person, and that’s why I’m complaining. When I see a post that starts off ‘I compiled GTK+ from source’ I reach for the coffee. I’m overall in favour of having autopackage (or something similar) available *and properly configured* on distributions. It’s just that so far as I’m concerned, ‘properly configured’ _definitely_ needs to include ‘installs somewhere other than /usr’.
AdamW: I’m afraid we’re stuck between a rock and a hard place then, I understand your concerns about users installing things to /usr/local, but if we did that with the current state of most distributions the desktop integration we put so much work into would … well, break.
I think a better solution would be to ensure that /usr/lib always takes precedence over /usr/local/lib, this must be possible and if it’s not patching the glibc dynamic linker to make it possible would not be too hard. I know my way around in that codebase, unfortunately :/
Mike: Yes, this involves running a shell script however it’s all “in the clear†and anybody can read it to prove to themselves it hasn’t been hax0red.
How many of the novice computer users you’re targeting will (a) think to do this, and (b) be able to understand the results even if they did…?
Adam, thanks for the reply. I’m just an enthusiast and advocate. But I agree with you that /usr will result in more conficts with native package systems that necessary. Or what happens when I’d like to switch distributions with 50 autopackages installed?
However, when I see two parties — one interested to have /usr/local/lib added to the default ld.so.conf, and the other interested in having autopackages install by default in /usr/local (or /opt) –, I see a potential agreement.
Since the wide spread use of autopackage is independend of distro support, they will have to deal with the consequences of its existance anyway.
Also, if I would be a paying user of a distro, I would expect my distro to set up a sort of online repository for autopackages as a special service (maybe in collaboration with DSL providers who need legal stuff as a sales argument). Otherwise I would have to deal with keeping copies of these packages around, watch for updates, and back them up: that’s a lot of work. Such a special service does not only mean more recent packages for users, it also means less human resources spend on packaging.
Autopackage’s existance also means more public exposure of software by journals, more potential users, and maybe higher returns. For example, in germany’s Linux newbie journal, MDK is not supported officially. If I would be a commercial distro maker targeting private users, I’d embrace and integrate such a technology as fast as I could — and since autopackage is FreeSoftware, this shouldn’t be really hard to do.
clausi: yes, and I’m going to start a thread titled something like ‘what to do about autopackage’ on the Cooker mailing list soon. my choice would be to package autopackage with a patch to the default config file and have the installation of autopackage set up the environment appropriately for installation into /usr/local, but we’ll see what happens.
Mike: What you’re telling me (and Joey) is that the Autopackage project is the sole source for ideas about autopackages. That’s not terribly open.
Not to mention that you are causing us headaches by installing to /usr. Getting alien (or other tools) to grok autopackages is a way for us to alleviate our headaches. When you say that you deliberately make it difficult for us to work with your packages, you only confirm my initial impression that autopackage is harmful.
Regarding breakage: if you get your way, we distros break. If we get our way, you break. That’s the status quo. Given the power distro vendors have, I would be willing to bet that you lose more often than we do. Of course, we could proceed by looking for ways neither of us can lose, but it isn’t helpful to hear you shoot down suggestions based solely on how your life would be more difficult.
clausi: I think we’re all in agreement that autopackage’s goals are a good thing. The question is whether we can reach them without causing pain for the distros. Also, switching distros is difficult enough; autopackage will be the least of your worries.
If autopackage doesn’t respond to these problems, I think most distros will consider autopackage use to void support guarantees. I could see a question added early in support calls: “type ‘which autopackage’ at the shell prompt and tell me what you see” (or some other telltale sign). Get enough of those, and autopackage will start becoming distinctly less popular.
Jeff, I’m afraid I don’t know what you’re talking about when you say “at you’re telling me (and Joey) is that the Autopackage project is the sole source for ideas about autopackages. That’s not terribly open.”
What I said is that the bulk of the package format is not documented because it’s an implementation detail and subject to change without notice. This means Alien cannot parse it. That’s very different to saying we’re the sole source of ideas on anything. We already suggested the solution: native package manager integration, not Alien. The end results would be the same, the databases would stay consistent and apt wouldn’t try and blow away pre-installed software.
Installing to /usr – I think we’re going around in circles here. I already said I’d be happy to fix this *if* and only if distributions make /usr/local a first class citizen: that means full desktop integration. The other solution is for autopackages to register with the dpkg database, so apt does not blindly attempt to overwrite their contents.
I think we all agree this is not an ideal situation. AdamW explained why Mandrake does not make /usr/local work properly. I don’t agree with his reasons at all, but I proposed possible solutions he may find useful nonetheless. The solutions are known and are just a matter of coding, so why don’t we get started?
I don’t intend to “shoot down” any suggestions, however saying we should change the defaults to /usr/local when I already explained my reasons for doing so doesn’t give me any reason to change my mind. You say that this will break distros, but really it will just break autopackage as the behaviour of many package managers is to blindly overwrite any files that weren’t placed on the system by themselves. So the autopackage database will end up with bogus entries, and apt will be correct. This means *we* will get tech support requests, not you.
I think I will ignore the various implications you make about how distros will use their “power” to make autopackage less popular if we don’t jump. It’s not my life that would be made more difficult, its our users lives.
Final note for AdamW: please do not pre-install autopackage with defaults different to upstream unless you ensure /usr/local works correctly, that means it’s in the linker path, the KDE path, XDG_DATA_DIRS and all the other points I mentioned. If you make /usr/local work right we can change the default for Mandrake upstream anyway. If you set the defaults to /usr/local without addressing the concerns that led to use /usr, then you’ll only succeed in making users even more unhappy. I will be keeping an eye on this.
Mike: We get that the package format is an implementation detail. We’re trying to tell you that this is the wrong way to do it.
Furthermore, we are all dependent on you to solve our problems. If you don’t think it important to solve this particular problem right away, what can we do? Basically, fork Autopackage. Alien might have been another way to solve this problem, except that you’re hostile to us doing things the way we think might help. This is not openness.
Essentially, you’re telling us that Alien is the wrong way to solve the problem. We disagree. If your system was open, we could try our way, and you could try yours, and we could decide then which way works better. But your project isn’t made that way, so we have to do things your way, whether we like it or not. You might call that openness, but we don’t.
You say that this will break distros, but really it will just break autopackage as the behaviour of many package managers is to blindly overwrite any files that weren’t placed on the system by themselves. So the autopackage database will end up with bogus entries, and apt will be correct. This means *we* will get tech support requests, not you.
This is incorrect. I say this because my day job involves building custom distros, based on both RPM and Debian, and we’ve investigated it. My job would be much easier if you were right.
Sometimes, things will work OK. Other times, the two packages in question will be configured slightly differently, and will incompletely overwrite each other. When this happens, you will often see that the one version sees the other version’s data and uses it, which is often incorrect, or it doesn’t see data the other version set up.
Example: Firefox. Version A uses .mozilla-firefox for user settings; version B uses .mozilla/firefox. Start out with version A, use it for a while, upgrade to version B. Voila: you just “lost” all your bookmarks, extensions, custom settings, etc. And if version A was the autopackage version, and version B was the distro version, we’d get that support call, as it would look to the user like the distro broke Firefox with the last upgrade.
(Not to mention that, in the case of support contracts, the responsible support person will likely get all support calls, regardless of the cause.)
Regarding “power” and making users’ lives difficult: we believe you’re making our users’ lives more difficult right now. Why is it more acceptable for you to break our package manager than it is for us to break yours? This is particularly apt when reading your comment to AdamW. If he packages autopackage and doesn’t fix /usr/local, what are you going to do? Embed code in Autopackage to subvert Mandrake’s design decisions?
We’d rather not have a war, but if you insist…
Regarding cooperation: I’ve already downloaded the source for autopackage, and will likely have time to play with it this weekend. (BTW: please distribute real source tarballs.) Despite some of the hostility, I still think the goal here is good, and Autopackage is at least a good start. Whether the final, fixed solution will be Autopackage, or a fork of Autopackage, is up to you.
I see two major opinions here, one from distro vendors and one from autopackage developers. I’d like to give one from a typical developer’s standpoint. I’ve known of autopackage for a while, and fully plan to support it in my projects. Why? Because it’s a royal pain to get things in a distro sometimes. I understand the desire to keep packages in a distro under control and to not have autopackage screw it up, but if you think that you have any control over it right now, you’re mistaken.
Jeff, your claim that installing autopackages will cause trouble for Debian users later when they install an official package is bogus. dpkg and apt-get do not care if you have files sitting around that don’t exist in the package database. It’ll overwrite them. Autopackage isn’t this brand new thing that will hurt distros. It’s an easier way for us to get software to our users without a distro-provided package. The other option for us is to give them a tarball and have them make install. Certainly that’s more common than autopackage installs are.
I don’t believe anybody thinks that every packager should move to autopackage and away from native packages. In my Galago project, I’m trying to provide Ubuntu and Red Hat packages along with autopackages so that users who use Ubuntu or Red Hat can install them with their native package management software and everybody else can grab an autopackage. Still, some people will probably provide only an autopackage. This is fine, because it’s not like there aren’t any projects providing only tarballs. Let the developers provide their software however they see fit, and you guys can get to work on packaging them for your distros. It doesn’t have to turn into a conflict between distro packager and software developer. Both can have their ways.
As Mike says, once everything supports /usr/local properly, they’ll introduce support for that. Seems fair to me. I tend to install a lot of things to /usr nowadays when compiling from source because /usr/local isn’t always recognized out of the box. It’s not the autopackage team’s job to fix that. You guys have the ability to, right? Perhaps you guys can work with Mike to fix these problems, instead of just being vocal about them.
I apologize if any of the above seemed less than polite. To say I didn’t sleep well would be an understatement. Still my points remain. Being someone who tried working on a packaging solution in the past and got discouraged by how much people chose not to get along, I’d really like to see something like autopackage take off, with support from distro packagers. We developers would appreciate it.
Christian, I agree that autopackage is a good idea in theory. I (and others) just have problems with the implementation.
Jeff, your claim that installing autopackages will cause trouble for Debian users later when they install an official package is bogus.
As I said to Mike above, you’re wrong. I’ve even given an example of just one way this can break. There are other ways.
But this isn’t really productive. We can name-call all we want. Wouldn’t it be better if we all didn’t assume that other people’s objections are wrong by default? I mean, you called my objection bogus, despite the fact that I very likely have a lot more experience with the problem than you do.
I’ve already done my part, in admitting that the goal is good, and in pointing out other things the autopackage people do well, and in committing to look further at the problem.
Mike: yes, that’s what I’m going to recommend (note I’m a copyeditor and general busybody, not a packager in my own right) – get /usr/local fixed. The having an autopackage package which is patched to use /usr/local by default would be a temporary arrangement until you change the default upstream, at which point the patch would be dropped.
I think we all agree that the solution here is ‘fix /usr/local’, which I’m happy about :). I’m just not particularly happy there’s a version of autopackage out there at the moment tagged ‘stable’ and encouraging widespread use which has IMHO fundamentally wrong behaviour (installing into a location that should be off limits for anything except the distribution packaging system). The situation in which installing to /usr could break the distro, btw, is when you get to a half-and-half situation, with interdependent stuff mixed up between autopackage and distro sources.
I appreciate you have a neat product that you’re proud of and that you want to get out there and start helping the experience of users, I’d just have been a lot happier if your project had made a real bona fide effort with distro vendors to get /usr/local fixed *before* shipping with /usr as default. From MDK’s perspective, just a mail to the Cooker ML explaining the problems you have with using /usr/local on MDK and why it would be a good idea to fix them would certainly have kickstarted a debate that could well have led to the issue being fixed; I don’t remember seeing such a mail.
Oh, and one more thing – remember, users don’t always send support requests to the right place. If they install something with autopackage, it works, then they do a system update which tramples all over the autopackage installation as you describe and the program stops working, they’re at least as likely to complain in a distribution place as they are to complain in an autopackage place. Remember, users don’t know the mechanics, all *they* see is ‘gaim was working, I ran $DistroUpdate and now it’s not working, $Distro sucks, now I’ll go complain!’
Adam, I think your idea about packaging autopackage with using /usr/local as default is a really good compromise, additionally when Mike says that they can include the change upstream without problems when they get a notice. Hopefully the compromise will be used by MDK and others, too!
Posted this message to MDK Cooker mailing list:
“What are we going to do about autopackage?
They recently shipped 1.0 and are getting some momentum. It is (IMHO,
and that of others, including Debian guys) horribly broken as of now, in
that it installs into /usr by default, walking all over distribution
standards. However, if it played nicely and installed to a sane
location, it could be a good thing for MDK overall, especially for users
who like to update small programs between MDK releases.
I propose the following. We fix the distribution so that installing
stuff in /usr/local _really works_. This involves adding /usr/local/lib
to /etc/ld.so.conf and /usr/local/bin to the default paths, at minimum.
(Mike Hearn can provide more information on other things that have to be
fixed). We then inform the autopackage project that MDK is clear for
installation in /usr/local , and they will make autopackage install
in /usr/local by default on MDK. In the interim, we can ship a packaged
autopackage with the config file patched to install in /usr/local by
default.
Comments?”
AdamW: thanks, this is exactly the sort of thing I wanted to see happen! Let’s see how well it goes. I’m not subscribed to the cooker list, but will watch in the archives or via GMANE.
ISTM that the effort that people are using to ship software packaged with Autopackage would be better spent building LSB-compatible RPMs, which will properly integrate into the package systems of Fedora, Mandrake, Debian, Ubuntu, and every other LSB-supporting distro. If that means you ship a somewhat-statically-linked binary (for example, because you can’t depend on GNOME and KDE libraries), so be it.
Or, fix Autopackage to internally build a RPM or DEB and send that to the system package manager for the actual installation, so the PM can deal with whatever issues arise with file conflicts.
Either approach would be much better than just blindly stomping all over the filesystem.
Ok, first off I’m just a “lowly user” here, but I see Autopackage 1.0 as being quite possibly the single most important thing to happen for the Linux community since Linus’ 1.0 release of the kernel. When I began my journey into the Linux world a year or two ago the first thing that I noticed was how horrible the “packaging” situation was. I tried many different distros and was very disapointed with every single one of them (I ended up using Gentoo b/c portage is very easy and stable). The “Linux distro” is an operating system…right? Then why do I as a user have to rely on my distro to provide every program I could ever want??? That’s a very backwards way of running things… Distro guys should only worry about low level, system type stuff and those programs and your “3rd party” programs should be stored in two completely seperate locations. I really think the old Unix style filesystem is obsolete and I should be installing my programs to “/programs/local”…lol; but I’ll leave those decisions up to you guys….
I’ve done tech support for friends and family (and currently as a job) for many many years, and the sad truth is that 90% of people don’t know the first thing about how their computer works. When I try to tell these people about the benefits of Linux I feel morally obligated to tell them the truth about the installation limitations holding Linux back from the mainstream. I truely belive program installation is the biggest problem holding Linux back from widespread use right now. If an end-user could just download a file, click an icon, install it and then use it, Linux would be unstoppable! This is why I see Autopackage as such an important project. If the current “distro guys” don’t want to deal with Autopackage, then we end users will be looking for differnt distos.
“Mike: Yes, this involves running a shell script however it’s all “in the clear†and anybody can read it to prove to themselves it hasn’t been hax0red.”
Humans reading it are one thing, but the biggie is programs reading it.
What Joey has written is inflammatory enough to get people’s backs up and overlook the fact that he raised some very valid points. I probably will never use autopackage (not out of spite, but I’m a debian user so I’m unlikely to ever need to) so any suggestions I make are entirely aimed to help out. I’m interested in making sure that if autopackage takes off, it’s designed well and is flexible enough to be useful in a number of circumstances.
Jon – there’s no point in allowing programs to read autopackages, as they aren’t simply containers. They’re programs. If you don’t trust upstream to provide a solid package, why are you using their software at all? Surely you can’t trust one but not the other, that makes no sense.
Now, I still don’t really see where Joey is coming from. Even if the contents could be dumped out without running code, the actual files would be meaningless as autopackage does some post-processing on them. This will happen more with time, if we go ahead and integrate things like LLVM or switch from bzip2 to LZMA compression.
If you can give me some solid use cases for being able to dump the contents without running code, that aren’t converting between package formats, then please do let me know. Otherwise it seems to be that it’s over-paranoid: if you don’t trust the package there’s no reason to trust the binaries inside them either, at which point the wrapper becomes rather academic.
Mike, that’s the whole point of our criticism. There’s no point in reading autopackages because you designed it that way, but you didn’t have to design it that way. Most of your innovation, from my ongoing look at it, comes from your relocation and dependency handling, not from the fact that your file layout and metadata are opaque.
It would be easy to take what you’ve done and give it proper transparent containment and metadata. And it turns out that a lot of us want that, judging from this comment thread alone. Some people might consider that evidence that it would be a good idea, regardless of whether they could write use cases or not, but I guess that’s not you.
You also confuse our trust in the program’s author with our trust in autopackage. Obviously, the original program’s author didn’t write all of the code that unpacks and sets up the autopackage. And just because we don’t want /usr munged by some random thing doesn’t mean that we don’t trust the AbiWord people to write good code otherwise.
Can we give you solid use cases? Sure; we gave you one, that you just dismissed as illegitimate for reasons I don’t understand. Would it do any good to give you more, if you have so little respect for the ones we do give you?
[edited – stupid comment by me about an example of autopackage breakage that turned out to not be autopackage’s problem. Next time, I should read the whole thread.]
Hi, I’m speaking for myself, I’m not part of autopackage, not speaking for it, etc. I do build the gaim .package’s
What’s all this talk about /usr getting munged?
Have you guys never heard of rpmfind.net? Have you never heard of –nodeps? Or ./configure –prefix=/usr (I’ve even seen some tarballs that default there) Have you not heard of .tgz 😉 Have you never heard of alien? (Obviously you have).
All those things install to /usr, and are more likely to be broken than an autopackage. If there’s no easy way to install software, people will just do it the hard way and mess things up more.
If you hate /usr, but don’t want to fix /usr/local either, there’s always /opt/autopackage. ./configure scripts don’t default there, so compiled by source stuff is unlikely to end up there, so it would be “safe” to enable by default, as only autopackages would install there (and only if you set up autopackage to install them there). That seems like a reasonable compromise.
Btw, openness doesn’t mean “do things our way instead of your way”. It seems rather close minded to complain about autopackage being, in effect, different from rpm or deb. It obviously had different deisgn goals and different priorities. I haven’t really seen anyone defend their complaints about the package format, and I don’t see why a user trying to install software cares about manipuating the metadata of the package format. IOW, rather valid or not, you haven’t convincingly explained why those things are important, or how their benefit outways the costs.
As for as forking goes, I doubt anyone has the time, energy, manpower, or interest to do it. If they did, they’d have already written their autopackage-like software., or else already be a regular contributor to autopackage and be having some fight with Mike on the mailing list where you end up agreeing to disagree.
Tim, I could respond point-by-point, but I think there’s a central message you need to understand: no technology is perfect. That includes autopackage. It’s always easy to accept that in theory, but can the autopackage people keep that in mind when specific allegations come out? That’s the critical test.
So, for example, you ding us because, as you see it, you don’t do things our way. That’s not true. Nowhere have I said that autopackages need to look like debs or RPMs, nor has anyone else to my reading. I think you’re projecting what you’d like our objection to be, instead of actually answering what our objection is: autopackages are opaque, and nearly impossible to manage from the point of view of a distro vendor or a sysadmin.
I’m not going to respond to the rest, because I think your attitude is the real problem. Suffice it to say that most of your objections are without merit, and the rest have already been observed. Package managers certainly aren’t perfect either, and I think autopackage has the potential to fulfill a need. But it won’t if you just think we’re all stupid.
A users point of view:
I’ve used Redhat, Suse, Gentoo and most recently Ubuntu.
All but Gentoo have the problem of getting access to new packages. It takes a day max (when I used it) for Gentoo to get an ebuild out, most often you just changed a version number in your portage database.
I have Crack Attack! and Inskcape installed in Ubuntu via autopackage because that was the only way of having the latest versions of them, Inkscape because they release their betas in autopackage format.
I’m smart enough to figure out that If I install something with autopackage I have to uninstall it with synaptic first. (In windows most programs tell me that I have a previous version installed and it asks me if I want to remove it first.)
Distributions are too slow to ever keep up with new packages. As long as “you” distros keep your own packaging formats we’ll need “>make install” or autopackage, wich would you prefer? On redhat I used make install for many things, did it break my system? Sometimes, what to do? reinstall the whole of redhat since there was no “make uninstall”.
I used autopackage for something I can’t remember now, it broke my system but I just uninstalled it and replaced it with the older repository version, everything went back to working order.
How do we expect to compete with Microsoft when I can’t agree on a single package format?
Why don’t you all take a look at what kind of metadata you use in your packages, pool them all togeather, decide on what compression to use and then make a freedesktop standard and stick to it.
Heck, put in a Distro tag so your desktop can warn you “This package is not built for your distribution, it’s built for Redhat/Fedora, installing it might break your system”
I’m using Ubuntu right now, and I can tell you that you don’t need Autopackage for the latest version of crack-attack. Inkscape, yea, they’re a point release behind the latest stable. Debian unstable is currently on package attempt 5 of inkscape .41. If you need nightly releases for some reason, you either need to convince inkscape it’s worth the time to create a nightly .deb, learn the proper way to use tarballs or convince autopackage and distros that it’s in their best interests to work together, perhaps via /usr/local or /opt. Given that /usr/local is the traditional place for installing new software, it makes a modicum of sense to continue this legacy. The path of Autopackage is clear; the status quo has glaring problems (overwriting current installs comes to mind). Act in the affirmative and make good choices and you’ll quickly find yourself an instrument of positive change.
A MESSAGE TO DISTROS
Breaking /usr/local is stupid and this is what it gets you: users facing a choice between your software schedules or deliberately breaking your system.
I would like to recommend to aks for World Peace. There are not too many mainstream distros. They shall team up and unify their ways. Autopackage is a nice project and addresses many of the problems we face today.
Perhaps the solution here lies in freedesktop.org standards. They already define several standards so that desktop integration and the like are easier to program for. This is important, as it is a pain for people to program for the various permutations of desktops and windowmanagers. At least thats what I understand, perhaps I’m stupid. Obviously there is a problem with comercial and 3rd party apps. Bringing mainstream comercial apps into the linux arena isn’t just a matter of porting. A major headache and obstacle is packaging. Loki had some things going for them with the loki installer – it was so easy to use. But now it is outdated, and it didn’t always work anyways. Menu entries were a problem. It is still a useability problem. I notice that when I installed svg with autopackage, it needed my root password. I was using Ubuntu and it failed as I use sudo with the root account disabled. The workaround was to activate the root accound, install the autopackage and then return my root account to the inactive state. The password thing bothers me. Any distro package system of 3rd party package system who wishes to have people in the mainstream use it can’t be asking for passwords as this gets quite annoying.
IMHO the solution is simple. Some linux users want 15 levels of security. Some users want to be able to point and click and have things just work without security overhead making their lives difficult. The best solution is to have linux distros offer a simple option during install.
——————————————————–
Welcome to linux, a secure, stabile, fast
and free alternative to Windoze and OSX
Please select your level of computer
expirence so we can provide the best
interface expirence for you.
_____________________________________
O 1 – Beginner – point/click – lower security
O 2 – Intermediate – more expirence – more security
O 3 – Expert – TONS of security, a little less easy.
Obviously I just made that BS up on the spot but you get the picure – a shell script could easily set the necessary security and permissions to make this work..
I am not so sure on the technical part and the vulnerabilities asscociated with it. But an Autopackage kind of thing sure is a great method to distribute third party stuff like device drivers. So that it could be installed just like the .inf files the Windows drivers come in, in any of the GNU/Linux distros. And we all need some distro neutral stuff atleast when it comes to hardware and device drivers, right? I hope and wish Autopackage will mature enough to become the standard format to distribute atleast the device drivers.
Happy GNUiing!
“Mike: Yes, this involves running a shell script however it’s all “in the clear†and anybody can read it to prove to themselves it hasn’t been hax0red.â€
Humans reading it are one thing, but the biggie is programs reading it.
I am a software developer but I do not develop for Linux, and know little about the details of Linux package management and the problems involved. As a Linux user however, I do know that i loathe and detest the way applications are “packaged” for Linux. In fact I even hate the term “package”.
The operating system and the applications should be completely separate in the same way a cd player and the cd’s are. To amalgmate the operating system and the applications into a single entity seems to me to be the biggest blunder the IT idustry has ever made. How could anyone have ever thought that having all the aplications bundled together in one database would be a good idea? The sooner this absurd situation comes to an end the better.
I dont know if Autopackage is actually a good solution to this problem, but it or something like it is needed very badly.
When I download a “distro” i want it to be the operating system – no more no less. Like Windows. The kernel, device drivers, system scripts, and a few basic simple applications (editor, terminal) and a basic gui (kde or gnome with minimal apps). All other applications should come from the web sites of the applicationm authors or independant web sites like Freshmeat, etc.
Except, of course, that Windows isn’t quite “just an operating system”, either. You have IE, Windows Media Player, Windows Messenger/MSN Messenger, Notepad, etc. They’re even skewing Vista to favor certain web sites (their own, of course).
I agree that Linux distros are only just starting to think about the question of third-party application installation, and that’s a problem. But I don’t get two things about your opposition to packages in general.
First, why is it so bad to be able to pull up a window and install a broad base of applications without having to go find them?
Second, Windows-style installing has its advantages, but also its drawbacks. One of the reasons viruses and worms are so difficult to do for Linux is that the OS takes responsibility–via the package manager–for some of the tasks of software installation. This doesn’t mean that distros have to package *everything*, of course, but it does give packages some compelling advantages; it’s certainly not an “absurd situation”.
Hope you come back; I’d love to hear your take on this.
As a technically competant user, I tend to disagree with the entire idea of autopackage. If you’re not going to produce debs or RPMs, please, for the love of Linus, give me a tarball.
That said, I can appreciate the need for less geeky users to have a simple point and click method of installing packages. However, the current behavior of installing in /usr is completly unacceptable.
Honestly, I don’t give a damn what their reasons are. It’s a blatant violation of the FHS and (more importantly) the FSSTD. If one aims to be distro independant, these standards are your friend and you should respect them.
Despite the claims to the contrary, installing into /usr can and does break the packaging system. If broken /usr/local creates some hassles on your end, put some entries in an FAQ or something. Sheesh.
Nice overview but have there been any updates to this since 2005? Seems like there must have been – in technology 6 years is a long time…
@Rick K / Cash Tornado
AFAIK, Autopackage is still not the standard way to install apps. The way it most of the time requires root access to install anything will definitely not go well with 90% of the linux users. Why do you think windows users get new malware every other day.
A few distro’s have adopted it but I don’t see it picking up anytime soon.