1.0 on March 26th. Autopackage is a "multi-distribution binary
packaging framework for Linux systems
." To put that in layman's
terms, Autopackage is something like an InstallShield application for Linux
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.
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
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
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
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
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.
Comments (38 posted)
is an interesting site. In
its simplest form, it provides a sort of centralized bookmark service.
Bookmarks are stored in a flat structure, with any of a number of "tags"
assigned to them. Since the bookmarks are stored on the server, they are
available anywhere on the net. The tags and bookmarks are absolutely
public, so anybody can see what everybody else is interested in. The site
as a whole forms a sort of spontaneous index of the web, sorted by
popularity. del.icio.us has attracted a great deal of interest as a
collaborative guide to the net as a whole.
It is not surprising that competitive sites would pop up. Still, many
del.icio.us users were surprised by the debut of de.lirio.us, which differs in these
- The name is different by at least five pixels - on a high-resolution
- The code is open source (though the license is unclear at the moment).
Users of del.icio.us are somewhat annoyed. The creation of an outright
clone strikes many of them as dishonest, and they would rather have seen
the effort go into creating a better "folksonomy" at the original site.
Most of them see little reason to put any effort into an imitation of
del.icio.us when they have the real thing.
The advent of de.lirio.us does raise some interesting questions, though.
Does the open-sourcing of the code justify the creation of a clone site?
Steve Mallett, the creator of de.lirio.us, seems to think so. (Steve is
also, incidentally, the OpenSource.org
webmaster and the editor of OSDir). The
Linux kernel was created for very similar reasons; it was a clone which
made an established interface available as free software. To the extent
that the del.icio.us interface was successful, it made sense to copy it
rather than invent something new, but less effective. The new site perhaps
could have tried for a slightly different look, however.
One del.icio.us user questioned
the wisdom of making this sort of software free in the first place:
The biggest issue with open sourcing social software is that I feel
it's counterproductive: the issue of fragmenting the userbase into
a thousand pieces is the main problem.... my thoughts are that,
paradoxically, more openness in the software would result in such a
fragmentation that it would have the effect of closing the
community up into discrete little parts. I think a more "Leviathan"
approach than "invisible hand" might be better here.
This is an interesting variant on the fragmentation argument: social
software must remain centrally controlled or its user community will split
asunder. Whether this is true - or undesirable - is irrelevant, however.
People have little interest in being forced into "communities" which do not
appeal to them, and, on the net at least, they will find alternatives.
Another event worth noting is that del.icio.us creator Joshua Schachter has
his intention to make a business out of the site. Depending on where
his plans take him, del.icio.us users could find themselves happier than
ever. If commercialization takes the site in the wrong direction, however,
many of those users who are currently upset about de.lirio.us may decide
that the existence of an open source alternative is not an entirely bad
thing after all.
Comments (6 posted)
We occasionally get a request for an update on how LWN is doing. It seems
about time for another one of those; it's been a while, and, besides, it's
a relatively slow news week.
Back when we started the subscription experiment, we set a goal of signing
up 4,000 subscribers. The good news is that we seem to have done that.
Between our individual subscriptions and the various group subscribers, the
current count is almost exactly 4,000. This is a major milestone, one we
are happy to have reached. Our thanks go out to every one of our
subscribers; it is you who make this whole exercise possible.
The bad news was probably pretty predictable from the beginning: 4,000
subscribers is not enough. Some of our costs (notably health insurance)
have gone up significantly, and others (outside writers) had not been
predicted at all. We also very much need to bring in another top-level
editor so that we can expand our content and do things like attend
conferences or take vacations without seriously straining the whole
So the push for more subscribers will continue. Exactly what form that
effort will take is still being worked out; it will probably include more
benefits for subscribers (without taking anything from non-subscribers),
some attempt to expand the content mix, and a more focused sales effort.
Making all this happen with the current staff will be a bit of a reach;
we'll get there, but we ask your indulgence if LWN shows occasional signs
of stress in the mean time.
Thanks once again to all of you for supporting LWN; it is a privilege to
write for such an outstanding group of readers.
Comments (32 posted)
Page editor: Jonathan Corbet
Next page: Security>>