The Big freedesktop.org Interview
Linked by Rayiner Hashem & Eugenia Loli-Queru on Mon 24th Nov 2003 16:24 UTC
Original OSNews Interviews Today we are very happy to publish a very interesting Q&A with major freedesktop.org members: the founder Havoc Pennington (also of Debian, Gnome and Red Hat fame), Waldo Bastian (of SuSE & KDE fame), Keith Packard and Jim Gettys (of X/XFree86/fontconfig/w3c fame) and David Zeuthen, a new member who's taking over the ambitious HAL project. In the article, we discuss about general freedesktop.org goals, status and issues, the role of KDE/Qt in the road to interoperability with Gnome/GTK+, HAL (with new screenshots), the new X Server aiming to replace XFree86 and we even have an exclusive preliminary screenshot of a version of Mac OS X's Exposé window management feature for this new X Server! This is one article not to be missed if you are into Unix/Linux desktop!
E-mail Print r 0   · Read More · 81 Comment(s) http://osne.ws/40v
Permalink for comment
To read all comments associated with this story, please click here.
On packaging
by Mike Hearn on Mon 24th Nov 2003 19:39 UTC

First of all, thanks to Eugenia and Rayiner for a great read. Let's take a look at where autopackage was mentioned.

The argument that RPM is sufficient is worth examining. The theory goes that you can have a single RPM that works on all distros. That's sometimes true, and in those cases, great. Of course it won't integrate quite as nicely on Debian or Gentoo but tools such as alien do exist and using them is not such a hardship.

The problems come when it's not possible to have a single RPM. Typically that's because:

* The metadata used by the distributions is different.
* Different glibc versions are used.
* Files and libraries need to be put/registered in different places

(2) is kind of a red herring, there's nothing inherant in RPM that makes this a problem, but the RPM build tools don't really warn you about it or make it easy to avoid. Maybe in future apbuild will be more widely used, and this will become less of an issue (it will always be a compromise).

(1) and (3) can cause problems. RPM cannot have multiple sets of metadata, the format and tools don't allow it and extending them to do so would be problematic. If distro A calls the Python runtime "python" and distro B calls it "python2" then you have a thorny problem.

Let's not even go into the issues of Epochs and such.

(3) is not often so much of an issue, but it can be sometimes and RPM doesn't make dealing with it easy. You could move them/munge them in post-install scripts, but then the file ownership metadata is wrong and so on.

These things cause the RPM culture to be one of "one RPM for one version of one distro". Part of the hope is that a new installer framework will start with a new culture - one of binary portability. While it's true that RPM works fine on Solaris, how many Solaris RPMs have you seen on the net? I haven't seen any. I'm not interested in making a new package manager with a new format, I'm interested in making installers that work "anywhere" (restricted to linux/gnu).

There are other advantages to using autopackage I guess, none of them seriously important. You can mix source and binary installs more easily. I think the specfile format is nicer. I'm not interested in getting into a pissing match over features though, it's not worth the effort.

The final thing to note is that autopackage is an installer framework, not a package manager. Yes, at the moment you have the whole "package remove" command thing going... in future I'd like to eliminate that stuff and go 100% with RPM/DPKG/portage integration. It's technically possible to have "rpm -e whatever" work fine with stuff not installed by RPM, so we might as well remain consistant and do it.

It's been years and we still have RPMs being built and rebuilt constantly, with millions of different files for different distros - if it's possible to unify that so the job only has to be done once, is that not worth a shot? I think it is. Maybe one day Havoc will agree with me ;)