Debian sarge and amd64

April 27, 2005

This article was contributed by Joe 'Zonker' Brockmeier.

One of the big questions surrounding the release of Debian "Sarge" (aside from "when?") is why the amd64 architecture is not making the cut. It's not as if the amd64 port is unready, as indicated by this status report from Andreas Jochens of the amd64 porters team.

Inclusion of amd64 in Sarge has been the subject of some heated exchanges on the Debian-devel list, as far back as July of 2004. To the average user, it probably seems logical that the amd64 port should be included, since the work seems to be done, and other packages like GNOME 2.8 and KDE 3.3 have found their way in. To get clarification, we invited comment from Jochens and Debian Release Manager Steve Langasek.

According to Langasek, the decision not to include amd64 in Sarge is strictly due to mirror space.

When sarge is released, the size of the Debian archive is going to balloon, as full mirrors are asked to carry all of woody, sarge, etch (the new testing), and sid. While it's true that there are many Debian mirrors that will be glad to make room for amd64 -- unofficial or not -- we also know that there are plenty of other mirrors that have limited space available for Debian, and some of them may have to drop us after sarge is released because of this size increase. Making the archive even larger by adding amd64 to sarge means more mirrors that will have to drop Debian.

After the release, Langasek said that the FTP team plans to put a solution in place that will allow "partial by-architecture mirroring for etch using the limited toolkit demanded by our mirror operators... At that point, we will be much better able to accommodate amd64 without penalizing the existing architectures".

However, some disagree that adding amd64 to the mirrors would be an unreasonable burden. Branden J. Moore, for example, says that the Debian archive is not that large compared to other distributions.

These are the numbers from a dh -h on the mirror I admin:

Debian: 111GB
Debian-cd: 51GB
Fedora: 152GB
Gentoo: 112GB
Mandrake: 240GB
RedHat: 71GB

While others mirrors may very well be suffering from space constraints... they do have the ability to use proper --exclude lines in rsync to avoid mirroring the debs from the archs that they don't want. I know it's not the best solution, as their Packages.gz file becomes bad, but it works.

Jochens is not offended by the decision to keep amd64 out of Sarge, and says it's a "good thing" that the release will be supported separately by the amd64 porting team.

This could even be an example how other Debian ports could be handled in the future. I view the Debian archive mainly as a source archive which can be compiled for a large set of different architectures. The most important thing is, that fixes for architecture specific problems will be applied to the package sources. Debian package maintainers usually do a very good job at this.

We were also curious about the criteria used by the release team to decide what goes in. For example, why were GNOME and KDE updated, but X.org will not be included until Etch? Langasek says that the decisions have to do with making sure that someone will continue to do updates for the software, and that it would not derail the Sarge release process:

So the KDE and GNOME updates have happened because the KDE and GNOME teams have worked with the release team to make them come about in a non-disruptive way. For X, which is very near the bottom of the dependency tree and one of the more hardware-dependent components of the system, I'm not sure any transition to X.org could have been non-destructive; and the X Strike Force, our X maintenance team, opted not to push for it. We all know that a stable release is going to be perceived as "old" by the end of its life cycle whether or not we succeed in establishing a predictable release cycle for etch, so the difference between shipping an X server that's three, six, or nine months behind upstream is small when weighed against, say, causing a one, two, or three month delay in a release that's already overdue.

As for amd64, this was never the release team's decision to make; we work closely with the FTP team in preparation of a release, but it's the FTP team who has to make the judgment calls about how our infrastructure will or won't scale to handle new projects... All the reasons for keeping it out are logistical ones that people are intent on addressing soon after the sarge release, and I have every confidence that this will happen in the timeframe for etch.

Indeed, even the GNOME and KDE releases now in Sarge are somewhat outdated. While Sarge (including amd64) looks poised to ship with GNOME 2.8, KDE 3.3 and XFree86, Ubuntu is shipping with GNOME 2.10, KDE 3.4 and a fresh release of X.org. However, not all packages in Ubuntu are newer than Sarge. Vim shipped with Ubuntu for x86_64 is version 6.3.46, while Vim is at 6.3.68 in the Alioth repository.

Even though amd64 will not be released to mirrors as part of Sarge, Jochens said that the release "is not 'unofficial' anymore".

It is supported by the Debian release team, the Debian kernel team, the Debian installer team and others. The only difference to other ports is that the binary package archive for amd64 is maintained by the porting team instead of the ftp-master team. Again, I consider this a good way to share responsibilities and an example for other ports.

Jochens also assured us that the amd64 team will be able to maintain the amd64 release throughout the Sarge lifecycle, saying that it is "mostly a matter of compiling the updated Debian sources when they become available...amd64 specific security issues will be coordinated with the Debian security team".

For all intents and purposes, it would seem that the discussion is purely academic at this point. Debian users who want Sarge on amd64 will be able to get it, though perhaps not from official Debian mirrors. For those who are interested in trying out the amd64 port, the project is currently hosted on Alioth with a Debian on AMD64 HOWTO.

Index entries for this article
GuestArticles	Brockmeier, Joe