Benefits for LWN subscribersThe primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!
March 30, 2005
This article was contributed by Joe 'Zonker' Brockmeier.
multi-distribution binary packaging framework for Linux systems". To put that in layman's terms, Autopackage is something like an InstallShield application for Linux users.
Autopackage is not an attempt to replace native package management -- it doesn't replace RPM, dpkg or any other system of package management for Linux distributions. Instead, Autopackage is designed as a packaging system for projects and vendors that wish to ship applications for multiple Linux distributions without having to make packages for every variant of every distribution they wish to support.
The Autopackage system is primarily designed for use with packages for desktop users, like Abiword, Inkscape, Gaim and others. The default front-end for Autopackage uses Gtk2, but there is a a Qt frontend available as well. It's worth noting that Autopackage is licensed under the Lesser General Public License (LGPL), which makes it suitable for free software and open source projects as well as proprietary software. The package format itself is a gzipped tarball with a "stub script" at the beginning of the file. It is, in other words, a sort of executable, self-extracting archive format.
[Autopackage screenshots] We tested a couple of Autopackage .package files on SUSE Linux 9.2 and the Ubuntu Hoary Hedgehog pre-release. For the most part, we were pleased with its operation. Autopackage is simple to use, and works from the command line or using one of Autopackage's GUI interfaces. When a user finds an application packaged with Autopackage, all they need to do is download the .package file and run it. The first time a .package file is installed on a system, it will search to see if Autopackage is installed. If not, it will download Autopackage from and install it, then proceed with the installation of the selected package.
The first package we tried to install was Abiword, which is available from
the Autopackage
downloads page or directly from Abisource.
We first tried to install Abiword on an Ubuntu Linux system. Unfortunately,
Autopackage complained that it failed to find the "enchant" spelling checker,
even though it was installed on the system in /usr/bin. We had
better results with the Abiword package on SUSE Linux, however, and were
able to install that package with no problems.
We tried the Autopackage for Inkscape next on Ubuntu, and found that it installed with no problems. We also tried removing the packages and re-installing them to see if there were any glitches or unwanted side-effects. The Autopackage system handled removing and re-installing the package just fine. We even used Autopackage to uninstall itself, and were able to do so without any problems. Overall, we were pleased with the operation of Autopackage.
Autopackage does have a number of limitations, however. First, it's limited to x86 systems. Third parties that want to package applications for Linux on other architectures will not be able to use Autopackage, at least for the time being.
The Autopackage system also does not integrate with the system's package management. This means that RPM or dpkg will not "know" about the existence of an application or libraries installed via a .package file. For some packages, this may not pose a significant problem. For example, if a user wished to install the Linux version of Yahoo! Messenger, it's unlikely they'd have other packages that depend on it or any need to manage the package via RPM or dpkg.
Another drawback for Autopackage is the lack of support for package signatures. The Autopackage FAQ discusses the rationale for this. Since Autopackage is not a centralized source for software, unlike Red Hat, it creates some complications for package signing.
Finally, since Autopackage depends on a working Network connection, it could pose a minor headache for users on dial-up who download their first Autopackage and then try to install the software when not connected to the Internet.
We didn't actually try creating any Autopackage packages, but from the documentation, it doesn't seem that creating an Autopackage is much more difficult than creating RPM or Debian packages.
The project is now working on bugfix releases in the 1.0.x series, and development towards the 1.2 release. The project TODO list provides an indication of where Autopackage is headed for future development.
The Autopackage team has a Flash installation demo and 4-step tutorial that show how easy it is to use Autopackage.
Overall, Autopackage is a very promising project. It makes it possible for
third-parties to distribute software for Linux users without the need to
create sets of RPMs and Debian packages suitable for many different Linux
distributions. It's also easy to use, and should require little skill for
users to manage. It's too bad that such a system is still necessary at this
time, but it fills a necessary gap until the day that Linux distributions
can settle on a standard base system and packaging format.
| Index entries for this article | |
|---|---|
| GuestArticles | Brockmeier, Joe |
Posted Mar 31, 2005 5:13 UTC (Thu) by jwb (guest, #15467) [Link] (6 responses)
Autopackage also doesn't seem to solve technical problems for anybody except proprietary software vendors. And honestly, who gives a flip about helping those guys out?
Posted Mar 31, 2005 8:29 UTC (Thu) by halla (subscriber, #14185) [Link] (5 responses)
Posted Mar 31, 2005 12:33 UTC (Thu) by arafel (guest, #18557) [Link] (4 responses)
Posted Mar 31, 2005 13:17 UTC (Thu) by halla (subscriber, #14185) [Link] (3 responses)
Posted Apr 1, 2005 15:03 UTC (Fri) by tzafrir (subscriber, #11501) [Link]
How do you upgrade an installation?
If there's a buffer overflow in ImageMagick that is fixed through the standard security updates of the distro, will it update with your Krita package?
Posted Apr 5, 2005 11:53 UTC (Tue) by ranger (guest, #6415) [Link] (1 responses)
By the time you release, I hope to have a solution for all current versions of Mandrakelinux (based on automated rebuilding from cooker). Dag may do it for you on Fedora, don't know about SuSE.
But otherwise I'll choose the only practical way: create one binary that peope can install in their $HOME and play with.
But, it won't work:
If your software uses QT/kdelibs, or just relies on large C++ libraries, then you must be careful. This is because of C++ Application Binary Interface (ABI) issues: GCC 3.4 broke C++ ABI (again), so software compiled with GCC 3.4 can mysteriously crash on GCC 3.2/3.3 systems, and vice versa. Because of this, we cannot guarantee that your software will run on all systems. At the time of writing, most distributions still use GCC 3.2, but GCC 3.4 distributions are coming and GCC 3.2 distributions are not going to disappear any time soon.
So, your "one binary the peope can install" probably won't run on both Mandrakelinux 10.1 (KDE built with gcc-3.3) and Mandrakelinux 10.2/2005 (KDE built with gcc-3.4). And, if it works for 10.1, if the user upgrades to 10.2, it will be broken by the upgrade too. A solution based on rebuilding from SRPM will prevent the first issue, and using an automatically generated distribution-specific release tag in the RPM solves the second.
Posted Apr 10, 2005 21:50 UTC (Sun) by FooBarWidget (guest, #10500) [Link]
Posted Mar 31, 2005 7:13 UTC (Thu) by dmantione (guest, #4640) [Link] (1 responses)
Posted Mar 31, 2005 15:55 UTC (Thu) by RobSeace (subscriber, #4435) [Link]
Loki Setup URLs, for those not familiar:
http://www.lokigames.com/development/setup.php3
http://www.icculus.org/loki_setup/
Posted Mar 31, 2005 8:34 UTC (Thu) by astrand (guest, #4908) [Link] (3 responses)
There is a standard packaging format: LSB has standardized RPM3. Installing RPM packages on Debian works great, by using alien. IMHO, an installation GUI should work as a front end to RPM or Alien. We are using this approach with the ThinLinc installation program, and it works great.
Besides, using RPM is a requirement if you want to be RHEL compatible, if I remember correctly.
Posted Mar 31, 2005 10:11 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)
There's more. This is from discussion on OSNews (answer on this):
Now Mr Hess is coming from the perspective of "how do I make alien support this", and he has discovered that you cannot. Good. That is also by design.
The right way to integrate autopackage with dpkg and rpm is for it to manipulate the systems databases directly, not to try and convert package formats ahead of time.
Translation from English to English: you see - installation of any program in Windows can bring break anything in your system down and make any other totally unrelated program shaky. This game of "russian roulette" is so good that we really should introduce it in Linux - otherwise Windows users will not feel at home. Autopackage makes such russian roulette real in Linux: congratulations.
P.S. Do RPM and DEB formats have protection against "russian roulette" style of work ? To some degree: a lot of work is done by package system and not by pre- and post- install scripts. Yet, there are still possibility of things going astray (but without cooperation there between different distributions it's quite hard to do more) so rigorous testing of distribution maintainers does the rest. Autopackage makes problem worse and simultaneously encourages installation of stuff from around the globe without help of distribution maintainers. To me it looks like clear recipe for disaster.
Posted Mar 31, 2005 23:13 UTC (Thu) by dvdeug (guest, #10998) [Link]
Posted Apr 7, 2005 13:11 UTC (Thu) by mikehearn (guest, #29106) [Link]
Debian and Gentoo have also both managed to patch, QA and deploy fixes for non-existent security vulnerabilities before.
In other words, I think your assumption that autopackages will be bad compared to distro packages is itself a bad one.
But we'll see. Only time will tell.
Posted Mar 31, 2005 9:57 UTC (Thu) by khim (subscriber, #9252) [Link] (9 responses)
Autopackage is something like an InstallShield application for Linux users.
Exactly. It's blob of untrusted software to be run with root permissions. Do we really need this ?
In Windows world there are changes to go away from installers like this (MSI packages) - not very efficient and somewhat clumsy, but anyway... So why will we need to introduce such abomination in Linux ?
Think about it: autopackage is tool where installation if "this oh so very cool rainbow calculator" can very well insert troyans in your coreutils package and later (when autopackage will be well-integrated in rpm/deb package systems) it'll be even easy to conceal changes in checksums. Is this really a step forward ? Gosh.
Posted Mar 31, 2005 10:46 UTC (Thu) by halla (subscriber, #14185) [Link] (8 responses)
Posted Mar 31, 2005 19:45 UTC (Thu) by khim (subscriber, #9252) [Link] (4 responses)
Where this idea come from ?
Biggest problem with non-distribution install is conflicts between packages from different sources. When you are using distribution packages this problem is mostly absent, but when you are trying to install different packages from different sources you need sandboxing (at the very least any change should be cancellable). And as Windows world showed delegating this cancelability to program creators is "totally bad idea"(tm) - package system should enforce some rules. See Windows Installer for some ideas - it's not great implementation of the idea but it's still better then InstallShit^H^H^H^H^H^HAutopackage.
Autopackage is good old "plug-and-pray" idea: run installation script and hope for the best. If it does not work... you are out of luck: there are few knobs to press and they are not readily available. This is biggest problem with installers in Windows world: if everything works fine, then user is happy. If installer does not work then you are reduced to dances with tambourines - there are no good way to track problems. Any installer can screw you system beyond recognition and there are no way to see what installer will do and there are no way to prevent suck screwups.
Posted Apr 1, 2005 12:05 UTC (Fri) by halla (subscriber, #14185) [Link] (2 responses)
Posted Apr 2, 2005 20:32 UTC (Sat) by khim (subscriber, #9252) [Link] (1 responses)
Have you really tried to do this ? Autopackage is very unreliable when KDE (or any C++) applications are concerned. It's not a solution, after all - It's band-aid (and poor band-aid). If you want to life in world full of band-aids you can as well switch to Windows.
I never said Autopackage is trying to solve non-existing problem. But it does it so poorly that then end result will be more frustration for users and more problems instead of less.
At least with .deb or .rpm I can find a way to make it work on my Gentoo-based system (did it few times with programs not included in protage). With Autopackage I can not: it installs fine, but in most cases it does not work and there are no hints to show me why.
P.S. Of course I have pretty minimal installation of Gentoo as sacrificial system (everything compiled with gcc 3.4.x, for example): do you really think I'll be comfortable enough to run strange scripts on my work system and/or install lots of unused stuff on my test system ?
Posted Apr 10, 2005 21:55 UTC (Sun) by FooBarWidget (guest, #10500) [Link]
"With Autopackage I can not: it installs fine, but in most cases it does not work and there are no hints to show me why."
Care to explain what exactly the problem is? There are other Gentoo users using autopackages but so far nobody has reported that it does not work. If there's a bug, then it must be fixed.
Posted Apr 10, 2005 23:32 UTC (Sun) by whocares (guest, #29180) [Link]
Posted Apr 1, 2005 3:37 UTC (Fri) by flewellyn (subscriber, #5047) [Link] (2 responses)
This thing looks like it'd really only be helpful for distributors of proprietary software. I'm not
100% opposed to people running proprietary binaries on GNU/Linux systems, but I don't think
it's a great idea for us in the free software community to be "giving away the store" to the
vendors of these programs. If they want to package binaries for a distro, they can build
packages appropriate to that distro.
Or, y'know, create static binaries, so as to avoid library dependency headaches.
Posted Apr 1, 2005 12:09 UTC (Fri) by halla (subscriber, #14185) [Link]
Posted Apr 10, 2005 21:59 UTC (Sun) by FooBarWidget (guest, #10500) [Link]
Apart from being one of the autopackage core developers, I'm also the maintainer of several open source projects. And telling everybody to compile the source code is not solution! You know, some people do care about having an easy way for users to install the software, even if the software is not in the distribution's repository. You say autopackage is only helpful to proprietary software, yet the only applications that use autopackage at the moment are 100% open source!
Posted Mar 31, 2005 10:22 UTC (Thu) by broonie (subscriber, #7078) [Link] (1 responses)
Posted Mar 31, 2005 11:01 UTC (Thu) by Wout (guest, #8750) [Link] (1 responses)
If the maintainers of rpm, dpkg, ... would agree on a backend database format then we could all keep using our favourite type of package without having issues due to differing package types. Vendors of commercial software could then (in principle) pick one type of package and use that on any distribution.
Posted Mar 31, 2005 12:55 UTC (Thu) by clugstj (subscriber, #4020) [Link]
Posted Mar 31, 2005 16:25 UTC (Thu) by cdmiller (guest, #2813) [Link] (2 responses)
Posted Mar 31, 2005 17:19 UTC (Thu) by halla (subscriber, #14185) [Link] (1 responses)
Posted Mar 31, 2005 23:25 UTC (Thu) by cdmiller (guest, #2813) [Link]
Posted Mar 31, 2005 18:33 UTC (Thu) by raven667 (subscriber, #5198) [Link]
Currently the choices for a software creator are to:
A) Have their software picked up and distributed by a vendor
B) Spend a lot of time making packages and tracking dependancies for every platform you wish to support.
C) Bypass the package system entirely and make && make install
D) Loki Setup, Autopackage or InstallAnywhere
Right now this is a mess, but I don't see any solution in sight. The only way to fix this in a sane fashion is to have one packaging system, one filesystem layout and one dependancy tree (similar to how Debian and Debian-variants can easily work together). Basically RHEL, Fedora, SuSE, Mandrake/Connectiva, Debian, Gentoo will all have to go away and be replaced by a standard Linux. Since these people think
1) They have the "One True Way" so they're sticking to their OS
2) They need to differentiate in the marketplace (this is killer)
This will never happen. It isn't technically as bad as the old Unix Wars, everyone is dipping from the same source tree, they aren't fully forked from one another, but they have enough niggling differences to make them practically incompatable.
Anyway, a rambling 0ドル.02
--Mark Tinberg
Posted Apr 1, 2005 4:15 UTC (Fri) by mcatkins (guest, #4270) [Link] (6 responses)
We've almost convincing the windows people that running downloaded files
without looking at them very carefully is not too clever, and here someone
is suggesting the same for Linux!
What I'd like to see is:
1) a package format that is *not* executable
2) force the user to manually download, and install the autopackage
installer first. Better yet, why not put the autopackage installer into
the standard distributions, so after a while, everyone already has it?
3) Change the installation process of a package so that the first step
is to create a .deb/.rpm/etc suitable for the local system, from the
data in the autopackage, and then install that.
This way, autopackage files play well with whatever local
package management system is being used.
And doesn't alien already do most of the hard work? Or at least,
is a starting place.
1 is pretty-much non-negotiable, before I would use autopackage
Posted Apr 1, 2005 6:41 UTC (Fri) by khim (subscriber, #9252) [Link] (5 responses)
If you'll think about it it's minor nitpick. I mean: sure enough .rpm or .deb is not executable. Yet both have pre- and post- install scripts. Isn't it the same thing ?
As far as our packages can contain random code we can not be sure that "net-downloaded random package" will keep system unbroken. So neither rpm nor deb and of course not ebuild are suitable for such approach. Not really. Yet Autopackage makes problem worse, not better! This is my grief. This is not a packaging system - this is installer like InstallShit^H^H^H^HAnywhere plus packaging system (and later part is poorly made, BTW).
Posted Apr 1, 2005 7:10 UTC (Fri) by mcatkins (guest, #4270) [Link]
I would maintain, however, that we shouldn't be encouraging people
to get into the habit of download+run (without putting on thinking hat).
Download+feed_to_some_program at least leaves open the possibility
that some checks occur, or could be added in the future, and thus is
a better habit to encourage - IMHO.
There is no replacement for "trusting" (to some extent) the source
of your packages!
My other comments still stand....
Posted Apr 1, 2005 10:37 UTC (Fri) by ballombe (subscriber, #9523) [Link] (3 responses)
No it is not. With .deb and .rpm, you can inspect the pre- and post- install scripts before deciding to install the package. You can also decide to extract the data without running the scripts.
You cannot do that in a documented way with the current autopackage format.
Posted Apr 2, 2005 20:11 UTC (Sat) by khim (subscriber, #9252) [Link]
And why the hell no ? It's just a script! Exactly like pre- or post- install scripts in .deb/.rpm! Sure if you'll find .rpm with pre- or post- install script 100Kb in size you'll probably skip this package (it's scary: what this #&*!^@&*#@ thing will do with my system?), but... difference is in quantity, not in size.
Basically: .rpm/.deb can be disastrous beasts, .package is always disastrous beast. First choice is better then second one, though not by very much.
Posted Apr 7, 2005 13:08 UTC (Thu) by mikehearn (guest, #29106) [Link] (1 responses)
The -d switch puts the package into "debug" mode: it extracts the payload and the metadata into the temporary working directory, then dumps you into a shell so you can explore or edit the internals. At that point, all the scripts are available for your perusal.
Posted Dec 27, 2005 17:54 UTC (Tue) by dontunderstand (guest, #34777) [Link]
He Guys you really disappoint me... why not use the concept of softricity but now for Linux... That is the real sandbox idea, and easy to update, safe ... , using streaming
Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds