Autopackage 1.0 [LWN.net]

Autopackage 1.0

Posted Mar 31, 2005 12:33 UTC (Thu) by arafel (subscriber, #18557)
In reply to: Autopackage 1.0 by boudewijn
Parent article: Autopackage 1.0

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.

(Log in to post comments)

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.