report from Andreas Jochens
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
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
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
These are the numbers from a dh -h on the mirror I admin:
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
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
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
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
on AMD64 HOWTO.
to post comments)