[Desktop_architects] Notes from autopackage author
bryce at osdl.org
Thu Nov 24 23:29:17 PST 2005
On Thu, Nov 24, 2005 at 02:33:11PM -0800, Dan Kegel wrote:
> Everyone knows we need binary compatibility between
> the various flavors of desktop linux, and the LSB
> is the project that's trying to make that happen.
> Mike Hearn didn't want to wait for the LSB, though,
> so he went and created "autopackage", which tries
> to solve the problem from the other side: figuring
> out what apps can do to achieve binary portability
> in spite of the fragmentation that's out there now.
> As a result, he's probably a good source of knowledge
> about what binary portability problems are out there.
> I asked him to write up some notes about what he's learned;
> the result is at
> - Dan
I can vouch for autopackage; Inkscape was one of the first projects to
make use of it, and we've gotten a ton of value out of it.
To use it with Inkscape, we had to make Inkscape 'binary relocatable',
which required a few modest patches to allow directory paths to be
remapped, etc. We were fortunate to have Mike directly help us
implement it, but the changes were not terribly invasive and look like
they wouldn't require too much work to add to other programs.
While we have been very fortunate in having many people provide distro
packages (RPM's, debs, ebuilds, etc.) having the autopackage has been
like a trump card. Over and over we find users who for one reason or
another have some trouble getting a given rpm installed on their
system, due to dependency, glibc, or other compatibility problems. Our
first response is always, "Have you tried the autopackage?" Invariably
within 15 minutes we have a happy user. :-)
Of course, unfortunately autopackage hasn't always worked 100% of the
time (especially back in the beta days), but generally this has been due
to an error by the package builder rather than autopackage itself.
Now, not everyone is a fan of autopackage. Some people think it is sort
of an impure solution to dependency management, since it takes the
Windows route of carrying along the dependencies with it instead of
working with the native package system. However, my take is that for
users who want things to "just work", autopackage fills that niche well;
and those people who are stubborn and want a "pure" system probably have
the fortitude and know-how to resolve all the dependency issues
directly. ;-) In any case, it gets the software developers back onto
software development and out of the business of helping users solve
package management problems.
More information about the Desktop_architects