The autopackage binary packaging framework [LWN.net]

The autopackage project is building a cross-distribution software packaging system. The software is being built by this group of programmers. The autopackage FAQ explains some of the project goals:

For users: it makes software installation on Linux easier. If a project provides an autopackage, you know it can work on your distribution. You know it'll integrate nicely with your desktop and you know it'll be up to date, because it's provided by the software developers themselves. You don't have to choose which distro you run based on how many packages are available.

[autopackage] For developers: it's software that lets you create binary packages for Linux that will install on any distribution, can automatically resolve dependencies and can be installed using multiple front ends, for instance from the command line or from a graphical interface. It lets you get your software to your users quicker, easier and more reliably. It immediately increases your user base by allowing people with no native package to run your software within seconds.

Autopackage aims to improve on some of the weaknesses of packaging systems such as RedHat's RPM, the RPM Package Manager: "What RPM is not good at is non-core packages, ie programs available from the net, from commercial vendors, magazine coverdisks and so on. This is the area that autopackage tackles."

The use of autopackage involves the package command line utility, or GTK2 and Qt versions of the Manger application. The GUI interface is designed to resemble the Windows InstallShield application. One-click package installation that is similar to Linspire's commercial CNR (click and run) package system makes installations simple. The user interface vision document explains some of the interface guidelines. The how to use document presents a quick tour of the system, and the autopackage screen shots show the software in action.

The autopackage system uses executable package files with the .package suffix, the package format has been designed with multiple distribution support as a primary feature. Automatic dependency resolution is being addressed by the use of Luau, the Lib Update/AutoUpdate Suite.

Issues that need addressing with autopackage include dealing with the upgrading of applications installed by other package management systems, securely managing the signing of packages in a decentralized package distribution environment, lack of a common desktop Linux platform definition, and support for platforms other than X86 and X86-64.

The success of the project may largely depend on its adoption by independent software applications designers. If a critical mass of applications is reached, end users will have sufficient motive to install the software, and the distribution vendors will have motivation to include the system in their base systems. Applications developers wishing to create .package files should review the Packager QuickStart document. A limited number of packages are currently listed on the autopackage downloads page.

Autopackage fills a software distribution niche between distribution-specific packaged software and source code that requires building by the end user. This seems like an area that is fertile for development, developers of lesser-known software applications would likely see their code more widely used if they provided .package files.

Version 1.0.6 of autopackage was announced this week, it includes bug fixes and other improvements.

(Log in to post comments)

The autopackage binary packaging framework

Posted Aug 18, 2005 10:22 UTC (Thu) by mbanck (subscriber, #9035) [Link]

Scott James Remnant (the current dpkg maintainer/uploader) also commented on autopackage in his blog today:

http://www.netsplit.com/blog/tech/autopackage.html

Michael

The autopackage binary packaging framework

Posted Aug 26, 2005 13:11 UTC (Fri) by mikehearn (guest, #29106) [Link]

Those three are all Debian developers, not independent application developers.

On impatience

Posted Aug 18, 2005 8:57 UTC (Thu) by dank (guest, #1865) [Link]

While I admire Autopackage's author, I disagree with his
approach to application portability.
I had a long discussion with him about the LSB.
He looked into it a bit, but rejected it when
he realized that LSB apps are not allowed to use
*any* shared library that isn't either (a) shipped
with the app or (b) part of the LSB, since that
meant they can't use things like Qt, which are
not yet part of the LSB. "But it's already installed
everywhere! It works! It's on every machine! Why can't
apps use it?", he asked. But just because one system
has Qt and another system has Qt doesn't mean that
the two Qt's are binary-compatible. Once Qt's ABI
(and C++'s ABI) are frozen, then we'll be able to do
it reliably. That's what the LSB is all about.
But Mike didn't want to wait.

And as a result, he's probably learning a lot
about application portability. Who knows, maybe
he'll come back to the LSB table some day...

On impatience

Posted Aug 26, 2005 13:16 UTC (Fri) by mikehearn (guest, #29106) [Link]

Well, there is waiting and then there's *waiting*. The LSB seems constitutionally incapable of providing the sort of platform ISVs need. At a recent meeting on porting applications to Linux, I asked how many LSB RPMs there were in the wild, and the LSB developers themselves thought there were maybe 2 or 3. In only a few months we already have orders of magnitude more autopackages and end users than that.

The LSB was a good idea, but it's let down by the implementation. It's likely that in future a new desktop Linux platform will be developed to meet the needs of typical open source ISVs.

On binary portability - not only are we learning about it, but we've extensively documented it and written tools to fix many of the problems. These go far beyond what the LSB provides.

Pointless

Posted Aug 18, 2005 15:31 UTC (Thu) by erich (subscriber, #7127) [Link]

Autopackage doesn't solve anything (dependencies, conflicts and such), and is a pointless effort. Even when they are aggressively promoting it.

Providing a proper package for your distribution is much better. Especially for Debian, once you provide an apt-getable repository (which is a one-line command), people can install the software just fine (as long as you bother to care for dependencies, which you will always have to do, also with autopackage!).

If you ever have used Debians tools (synaptic, aptitude and such) properly (and not made the old mistake of trying to do the same as in ancient rpm times, downloading the package manually, installing it, trying to get the dependencies right... common mistake! don't call dpkg, call "apt-get install"!) you will not want to go back to this.

There is no way autopackage can guarantee it will "integrate nicely". nor that it is up-to-date, because I would have to *check for new version myself*! Also it is not guaranteed, that the newest upstream version actually suits my needs best.

Oh, and upstream probably doesn't even have my architecture anyway.

So please just ignore this thing, whatever they actually claim they can do better... do not waste your time on this!

Aimed at Windows users

Posted Aug 18, 2005 15:46 UTC (Thu) by bkw1a (subscriber, #4101) [Link]

It seems to me that autopackage is mainly aiming to appeal to ex-Windows users by providing a flashy graphical interface for installing packages. I wonder if some of the autopackage gui guts could more profitably be re-used to implement flashy frontends for apt, yum, etc. (Not that there aren't already such things, but autopackage's is quite pretty.)

Personally, I'll probably still use apt, yum or rpm directly, but slick graphical interfaces have their place.

Pointless

Posted Aug 23, 2005 17:20 UTC (Tue) by elanthis (guest, #6227) [Link]

This is nonsense.

Manually install a new archive? Configuration? Manual management?

Why?

Autopackage: go to the vendor's website, click a Download button, software installs. Software is installed and runs, done deal, no further wasted time.

Furthermore, Debian's tools aren't an answer in the real world. Even their 10,000+ package database is still just a small fraction of the available softwre in the world. You can't depend on your distribution to package everything you need. And we can't expect third-party developers to package software in native formats like RPM or DPKG - you'd need 50 freakin' packages to satisfy all your users (Debian 3.1 version, Debian 3.0 version, Fedora 4, Fedora 3, Fedora 2, Fedora 1, Red Hat 9.0, Red Hat 8.0, Red Hat 7.2, SUSE 9.3, I could keep going and going here).

If you are an uber-apt-using-computer-nerd, then no, AutoPackage may not be useful for you. On the other hand, if you'd rather not spend time using the computer to work on the computer, but would rather use the computer to work on something else, AutoPackage is a great idea - it lets you install the software very quickly and easily and get on with more important things.

That said, however... while I think the AutoPackage idea is superb, the AutoPackage implementation of that idea is broken. AutoPackage makes the assumption that it has to work against the distros instead of with them. I'd much rather see a nice packaging system designed to work with a common-distro standard, like the LSB+, then try to be built on tons of rickety shell scripts that you really can't trust to keep working.

In all honesty, RPM or DPKG are already perfect file formats. The problem is that there is no standard of what dependencies are available or how to detect those dependencies outside of the small set of LSB libraries. AutoPackage could work just as well, if not better, if they simply said that an AutoPackage was an RPM v3 file that can only depend on a set of standard defined dependencies, with a central registry for listing those dependencies allowing cross-distro installation. (Remember that even non-native-RPM distros can install RPMs.) This is essentially what the LSB is, only its too small to be useful.

One good thing to remember, though, is that the AutoPackage project has provided some excellent developer tools which are useful to developers that aren't using AutoPackage itself. apgcc is a particular gem, allowing you to compile apps on your modern box that will run on older boxes, removing the need for you to ship multiple bianries and for your users to have to figure out which of the bazillion binaries you ship is correct for their system. (Which should never be necessary - click Download and Install should be all you ever need; anything more is a pointless waste of time.)

Pointless

Posted Aug 26, 2005 13:24 UTC (Fri) by mikehearn (guest, #29106) [Link]

Well, if distributions were interested in binary portability and inter-distro compatibility that might have worked, but they aren't. There was an effort to do what you suggested back around the autopackage 0.3 time, with an LSB working group to standardise package metadata but it went nowhere at all.

Pointful

Posted Aug 26, 2005 20:18 UTC (Fri) by rqosa (guest, #24136) [Link]

> Autopackage: go to the vendor's website, click a Download button, software installs. Software is installed and runs, done deal, no further wasted time.

According to the FAQ, Autopackage has no equivalent of "apt-get update", so to get fixes for security flaws, one would need to find out which packages have security flaws and then manually download the newest version of each such package. That would be quite a lot of "further wasted time".

Also, I consider it a waste of time to go searching through the web every time I want to find a program to install, rather than just "apt-cache search foo".

The autopackage binary packaging framework

Posted Aug 25, 2005 9:40 UTC (Thu) by k8to (subscriber, #15413) [Link]

Autopackage attempts to essentially "solve" binary incompatability through a variety of methods including acquiring a superset of all binary interface versioning across all distributions, a clever installer, and some tricky binary hacks.

The problem is huge, and the developers approach it with great hubris. This technology will remain reliable only in the arena of percentages and probabilities. Mistakes cannot be ruled out, but only best-effort avoided.

The general approach is of shortcuts intead of proper fixes. For example, not all distributions put files in /usr/local on various search paths, so autopackage installs all files in the distribution-province directories (as defined per Linux tradition and FHS) under /usr. Thus they cannot avoid future incompatabilities with the distributions they install onto unless all distributions coordinate with autopackages. Since autopackages are intended to be released independently, this is of course impossible.

Here is a conversation from a prior discussion of autopackage. My question first:

"apbuild only seems to cover libc issues, not issues with other libraries. Do you plan to cover all library interface changes?
For example, my distribution (debian) contains package names like libpng12, indicating that this particular package has gone through a total of 12 binary-incompatable interfaces changes. libpth is at version 14, and libcrypto++, for example, is apparently binary-incompatable with every release.
Other distributions do not even bother to rename for binary incompatabilities consistently.
How are these issues addressed?"

The autopackage developer, FooBarWidget, replied as follows:

"It's not possible to cover everything. In case of libpng: we try to work around issues by creating symlinks. But libpng is a pain, it's one of the messiest libraries around (in terms of compatibility). And sometimes packages have to static link small/obscure libraries to work around the dependancy problem. Those solutions are not technically attractive, but at least they work. Long term goal is to educate developers about proper library versioning and the importance of compatibility."

FooBar's view, esseentially, seems to be "when we try it, it works." I have essentially no faith that this is a reliable approach.