Hi,

There seem to have been quite a few threads here lately on the topic of installing software, why it's hard, what can be done about it and so on. It disappoints me that so many people posting here appear to regard the problem either as unsolvable, solved already, or non-existant. The constant stream of huge threads on the topic suggests that it's none of these.

I am the maintainer of the autopackage framework (http://autopackage.org/) which makes it easy for developers to produce "install anywhere" Linux packages, which combine the best elements of Windows-style installers with Linux RPM/DEB style packages.

They work on any distribution, provide an easy to use graphical frontend and support dependency checking and resolution. In essence, they are binary equivalents to source tarballs and support many of the same features such as having features that your system does not support disabled automatically, checking for features it does need, they can be installed to any prefix (and installation to your home directory for non-root users works out of the box), and it can also download and install exotic dependencies that users may not have. It provides a straightforward user interface and "one click" installs from web pages.

I would like to make a simple request of people who give help here (for I used to help people out here regularly as well about a year or two ago): when a Linux newbie gets frustrated with their inability to find an up to date package for their distribution, try pointing them to our website and/or user forum:

http://autopackage.org/forums/

where they should feel free to discuss this issue and may receive some helpful advice and guidance.

Even better, if they have skills that may be useful such as coding experience, fluency in both English and a non-English language for translation, a talent with art or web design or are simply good with people, we may be able to put them to work improving Linux software for everybody.

For those who believe this is a "solved problem", or who are convinced this cannot work, the autopackage FAQ has answers to some common questions or criticisms:

http://autopackage.org/faq.html

In particular see the "Why bother" discussion for why tools like apt or yum are insufficient for meeting the goal of usable and reliable software installation on Linux.

Autopackage is not only for open source software. We are in discussions with several well known commercial ISVs as well.

If you have any questions or constructive comments please post them as replies to this thread.

you lost me when you got to the
"desktop Linux platform"
part

i don't find the way it works now particularly difficult
but that FAQ made my head hurt

some of us don't know how windows works and when i have to use it i almost always end up breaking something because i am not in direct controll.

that don't really seem like something that needs emulating

There already is a desktop Linux platform, it's just scattered and inconsistent.

All it really means is joining dependencies together with virtual packages. So you can do "apt-get install desktop-linux-platform-1" and it'll go and install lots of things like GTK+, Qt, SDL, libart, and so on. Then developers can produce packages that only have one dependency which is very easy to satisfy rather than 20 dependencies which may be very hard to satisfy.

And don't worry. We're not seeking to replicate the problems Windows has. It's been quite carefully designed to avoid most of them in fact, though a few of the things haven't been implemented yet.

Question I have.... do you using static linking for autopackage packages?

That's up to the packager. Sometimes yes, sometimes no, sometimes a hybrid can be used whereby dynamic libraries are dropped into a private location like /usr/lib/foobar. That's similar to the MacOS bundle linking. By default apps using bundling linking will load their private copy of the library. To make it use the systems copy just rename or delete the bundled copy. That technique isn't used much at the moment but it'll become more common in future, most likely.

Another technique is to dlopen the things needed at runtime. I wrote a program called relaytool that makes this very simple to do.

The whole static linking problem has always been the biggest stumbling block in my mind. I personally don't care about wasting a little bit of disk space.. but having several copies of glibc or other huge libraries loaded into memory for different programs is unacceptable in my opinion.

That is a problem I have trouble seeing a technical way around. Some distributions (take Redhat for example) use horribly altered versions of pretty major mainstream libraries (I hate to use the glibc example again) and building a package that will work dynamically linked against that and the "vanilla" version of the same library sometimes isn't possible.

My worry with using a cross-distribution binary package system is that we will end up with a system that wastes resources and gets hurt when it comes to performance.

We monitor performance closely, generally it's not an issue. For most libraries autopackages use the systems copy of the library. That includes glibc. This is safe, we have special tools (like apbuild) which modify the program at compile time to be able to run on a wide range of systems, dealing with glibc is a part of that.

In a few cases, like GTKmm, it's statically linked. This doesn't tend to hurt performance because not many programs use GTKmm, in fact on most systems you'll only ever be running one or maybe two apps at once that use it. In the common case of only running one app that uses a library static linking results in higher performance than dynamic linking.

I don't think autopackage is really universal if it is only compatible with x86, right now there are about three major CPU architectures x86, x86_64 (or x64), and ppc sure you would have to use fat binaries or something to be compatible with them all but that wouldn't be to bad it would only be twice the size.

right now i have no working linux systems to try it out on so I cannot comment on how well it performs. the problem with C++ ABI's will go away with time, so we will be waiting. Compression will probably work really well with 2 binaries with different ABIs how different could they be?

Given that Apple have dropped PowerPC, there is really only x86 and AMD64. RPM based distros can be bi-arch, for instance Fedora is bi-arch and I think SUSE/Mandrake are heading that way too. That means they're 32 bit compatible.

Stupid distros like Debian or Gentoo </duck> manage to throw away all the engineering work put into 32-bit compatibility on AMD64 by having package managers that don't understand the idea of having multiple builds of the same package installed at once. If you run such a distro in pure64 mode you are running on a brand new architecture and cannot expect to run binaries from anywhere except what you compile yourself or get from your distributions repositories.

Long term, we are looking at the possibility of cross-compilers or generic thunks (like how Microsoft managed the 16->32 transition). For now, you need to be running a 32 bit compatible OS for autopackage to work, which I think is a reasonable requirement.

C++ ABIs are dealt with using delta compression in CVS, so that won't be an issue for too much longer we hope.

I could be wrong, but doesn't this verge on spam? It's gotta be very borderline...

This is rediculous... The first non-PPC macs (since the old m68k's) aren't going to be out till 2006 (at least 6 months down the road), and Apple has made no claim yet that they will be completely dropping there PPC product lines. On top of that, there are already plenty of people running Linux on PPC's so if your going to claim to be universal it doesn't make much sense to discount them.

Also, your 64 bit arguement seams to suggest you'll go with the greatest common denominator and make everything 32bit. I agree this is probably fine for a lot of things... but what is the point in investing in 64-bit architecture if nothing you run actually uses it?

I'm not familure with how debian does it... but Gentoo Emul-Linux-x86 packages are exactly what you describe Gentoo not having. I use these on my Opteron box so that I can use things like flash and 32 bit video codecs and it all works just fine.

You'll also note, according to the change logs, that Gentoo has had these 32-bit x86 libs for amd64 machines in development at least since October 2003, this is hardly a new discovery.

Sorry, but case-by-case hacks like those or the Debian equivalents do not count as "32 bit compatible" in my books: for that you need a bi-arch package manager so every package can have 32/64 pairings, not just one popular one-offs separately packaged.

Don't forget this is linux - there is no forced solution. If you use 64 bit architecture while 32bit is most common you can still compile from source. Or perhaps developers will make 64 and 32 bit autopackages. Then when such a time occurs as 64 bit becomes ubiquitous, perhaps 32 bit packages can be dropped and 64 will be the norm.

Oh I haven't forgotten.. I just find it funny that they call Autopackage "Universal" and then cut out support for architectures that even major distributions like Fedora Core support.