The Autopackage framework hit version 1.0 over the weekend, raising hopes that it may eventually change the Linux binary packaging landscape.
So far however, no major Linux distribution has adopted the multi-distribution packaging framework. With this release, the target is actually developers, rather than distributions, project officials said.
Applications for Linux are traditionally installed by either compiling the software on the local machine or with the use of a packaging framework that has already compiled the software into a binary format.
Currently the most popular and widely used packaging framework is RPM (which originally stood for Red Hat Package Manager) and allows for binary installation, uninstallation, verification and overall package management.
RPM is in use on all Red Hat platforms (Red Hat Enterprise Linux and Fedora Core) as well as Novell SUSE Linux and Mandrake. RPM is actually also the package manager currently recommended by the Free Standard Group as a part of the Linux Standards Base 2.0 specification. But RPM is not without its shortcomings, which is where Autopackage comes into play.
The 1.0 release of Autopackage is a milestone in that the project, according to its developers, is now mature and stable and promises backwards compatibility from this release forward. Numerous code and bug fixes as well as a new GUI managers are all part of the stable release.
Like RPM, Autopackage can install, uninstall, verify, build binary application packages and help identify dependencies. Where Autopackage differs fundamentally from RPM is that Autopackage’s goal is to provide portable non-distro specific binaries.
“RPM itself isn’t that bad. The Big Issue is that RPMs are specific to particular distributions and distribution versions and sometimes even patch levels of those distributions,” Autopackage project maintainer Mike Hearn told internetnews.com.
“Autopackage gets around that problem by being universal. It also provides a consistent experience for all users, which means we can improve it faster than every distro doing their own thing can.”
But don’t think of Autopackage as an outright RPM replacement. According to Hearn, RPM is good at managing the core software of a distro and is fast, well understood and supports features like prepatching of sources.
“What RPM is not good at is non-core packages, i.e. programs available from the net, from commercial vendors, magazine coverdisks and so on,” Hearn explained.
“This is the area that autopackage tackles. Although in theory it’d be possible to build a distro based around it, in reality such a solution would be very suboptimal as we sacrifice speed for flexibility and distro neutrality. For instance, it can take several seconds to verify the presence of all required dependencies, something that RPM can do far quicker.”
Though not likely to replace RPM for distro development, Hearn does expect RPMs to become less common for open source application developers.
“I think you’ll see RPMs become less common on sourceforge download pages, if only because they’re such a pain to constantly rebuild,” Hearn said.
Hearn expressed a need for tighter co-ordination of development between Linux distribution. In his view there is currently an unending list of things that differ purely through being apart.
The release of Autopackage 1.0 opens the floodgates and may well help to solve the distro differences issue and in the process enlarge the Linux ISV community, according to Hearn.
“I think now that we have open source developers actively distributing third party binary packages there will be much more demand for such a thing,” Hearn said. “Up until now the practice of distros simply adjusting each and every package for their own quirks has meant there hasn’t been much incentive to fix these problems.”
“Autopackage can help enlarge the ISV community on Linux.”