After two and a half years of work, autopackage 1.0 has finally escaped into the wild. It has a fundamentally new design, and offers an alternative system of software distribution and management on Linux. This article will talk about what this means for the Linux community, and what new directions and possibilities it opens up. It'll talk about problems remaining to be solved, and finally it will propose solutions for them. If you just want to see what autopackage is like, check out the screenshots or the Flash demo, available from the website.What is autopackage?
At heart, it's about allowing developers to provide binary packages that can be used by every Linux user, regardless of what distribution or desktop they run. While not perfect, its success rate is already high and will become higher in future. Though young, there are already autopackages of Gaim, Inkscape and AbiWord . It is also being used by much smaller projects such as the GtkQt engine or Lincity which otherwise would have no packages for most distributions, rendering them difficult and awkward to install for many users.
It has several interesting features apart from working on any
distribution: it understands dependencies and
can resolve them. It supports multiple frontends,
with both textual and GUI frontends coming out of the box. It
ships with a manager application that lets you uninstall
3rd party software installed using autopackage (and in future,
this will develop into a generic tool that works for all
packages). Most importantly, it's been designed with usability in
mind from the ground up.
"What idiots, a new package format is the last thing we need!"
To do things like support dependency resolution without depending on particular distributions or package managers, a new dependency model had to be devised and implemented. To provide binaries that would run reliably on a rainbow of machines, new tools such as apbuild and relaytool were written. To provide the flexibility needed to deal with a wide range of systems, a completely script/API based approach was used. To provide an aesthetically pleasing experience GTK+ and Qt frontends were developed. And finally, to make it simple even for non-technical users, the ability to bootstrap the whole thing just by running the packages themselves was added. To meet these requirements it would not have been possible to adapt existing formats.
There was an additional, psychological reason. By providing a new format, users who have been failed by the existing system have a concrete feature request to make of the developers - rather than being limited to vague expressions of dissatisfaction, users can ask developers for something specific to help them. As developers learn how to build autopackages, we can show them how to make their software easier to install by evaluating dependencies for stability, penetration (how many systems it's installed on) and so on. We can also teach them how to use programs like relaytool to relax dependencies. They can then begin to improve their software to be easier to install, for ease of installation - like usability - is not something that can be slapped on in five minutes. It must be considered while the software is built.
- "Autopackage, Page 1/2"
- "Autopackage, Page 2/2"
