Autopackage 1.0 [LWN.net]

Autopackage 1.0

Posted Mar 31, 2005 5:13 UTC (Thu) by jwb (guest, #15467)
Parent article: Autopackage 1.0

The problem with Autopackage seems social instead of technical. It encourage the behavior, common among users of other major operating systems, of finding random byte strings on the Internet, and running them through the CPU. When you install a package from the Debian archive, you are taking advantage of an editorial process that endeavors to make certain the packages can be safely installed and used. Furthermore Autopackage provides no mechanism for updating software, which is a far more difficult problem already addressed by apt and the others. Providing a means to install software but no means to apply security updates borders on negligence. Downloading and installing nonupdateable packages (RPM, deb, or Autopackage) from unknown sources is not a smart behavior and I hope it doesn't become the normal way of installing software on Linux systems.

Autopackage also doesn't seem to solve technical problems for anybody except proprietary software vendors. And honestly, who gives a flip about helping those guys out?

(Log in to post comments)

Autopackage 1.0

Posted Mar 31, 2005 8:29 UTC (Thu) by boudewijn (subscriber, #14185) [Link]

First, the habit to download applications from other places than the
distribution-sanctioned ones is also widespread in Linux, so there's no
need to be snotty about it. There are countless website hosted by
sourceforges that offer a range of rpms and debs...

And it's not just proprietory software vendors who don't like to create an
rpm for every distribution under the sun; Autopackage also solved my
problem very neatly. I'm the maintainer of Krita and I wanted to make
available a binary of Krita for people to test. Telling people to use a
source package was no option, because the source package of Krita includes
KOffice, and installing a KOffice cvs might hurt their existing
installation of their productivity tools.

So I used apbuild to build a binary, with ImageMagick and lcms statically
linked and made that binary available from my homepage. For a lot of
people it just worked -- I've had success on SuSE 9.1 and 9.2, Ubuntu
Warty, Fedora Core 3 and Peanut Linux. I didn't go the whole hog of
creating a complete autopackage, mainly because I didn't have the time to
figure it out, but for the bimonthly releases of Krita we are planning
after the KOffice 1.4 release in June 14 I am certainly considering
autopackages. I simply don't want to have to create debs and rpms and what
not for all the distributions out there.

Autopackage 1.0

Posted Mar 31, 2005 12:33 UTC (Thu) by arafel (subscriber, #18557) [Link]

for the bimonthly releases of Krita we are planning after the KOffice 1.4 release in June 14 I am certainly considering autopackages.

You're obviously free to do that, but you should understand that it will almost certainly reduce the number of people actually using your releases.

Until AP actually works with whatever package management is in use on the machine it's being installed on, it should be avoided like the plague. I *really* don't need something else playing around with libraries and stuff behind dpkg's back.

Autopackage 1.0

Posted Mar 31, 2005 13:17 UTC (Thu) by boudewijn (subscriber, #14185) [Link]

Reduce? Compared to having no binaries available? Are you serious? Of
course, if you are volunteering to make available debs and rpms for SuSE,
Mandrake and Fedora Core for me, I might reconsider. But otherwise I'll
choose the only practical way: create one binary that peope can install in
their $HOME and play with.

Autopackage 1.0

Posted Apr 1, 2005 15:03 UTC (Fri) by tzafrir (subscriber, #11501) [Link]

What happens when the user will want to use a newer version of Krita that will be eventually availble through the packages management system?

How do you upgrade an installation?

If there's a buffer overflow in ImageMagick that is fixed through the standard security updates of the distro, will it update with your Krita package?

Autopackage 1.0

Posted Apr 5, 2005 11:53 UTC (Tue) by ranger (guest, #6415) [Link]

Of course, if you are volunteering to make available debs and rpms for SuSE, Mandrake and Fedora Core for me, I might reconsider.

By the time you release, I hope to have a solution for all current versions of Mandrakelinux (based on automated rebuilding from cooker). Dag may do it for you on Fedora, don't know about SuSE.

But otherwise I'll choose the only practical way: create one binary that peope can install in their $HOME and play with.

But, it won't work:

If your software uses QT/kdelibs, or just relies on large C++ libraries, then you must be careful. This is because of C++ Application Binary Interface (ABI) issues: GCC 3.4 broke C++ ABI (again), so software compiled with GCC 3.4 can mysteriously crash on GCC 3.2/3.3 systems, and vice versa. Because of this, we cannot guarantee that your software will run on all systems. At the time of writing, most distributions still use GCC 3.2, but GCC 3.4 distributions are coming and GCC 3.2 distributions are not going to disappear any time soon.

So, your "one binary the peope can install" probably won't run on both Mandrakelinux 10.1 (KDE built with gcc-3.3) and Mandrakelinux 10.2/2005 (KDE built with gcc-3.4). And, if it works for 10.1, if the user upgrades to 10.2, it will be broken by the upgrade too. A solution based on rebuilding from SRPM will prevent the first issue, and using an automatically generated distribution-specific release tag in the RPM solves the second.

Autopackage 1.0

Posted Apr 10, 2005 21:50 UTC (Sun) by FooBarWidget (guest, #10500) [Link]

We have some ideas for working around even this problem. It involves compiling multiple versions of the same binary, and ship package binaries with different ABIs. During install time, autopackage can autodetect which binaries it should install. To save space, we could use something like xdelta if the difference between binaries are small enough. I might start working on it next week.