Re: When will amd64 be allowed in sid?
Quoting Adam Majer (adamm@galacticasoftware.com):
> Chris Cheney wrote:
>
> >When is amd64 going to be allowed to go into sid? It has been more or
> >less ready to go into sid since mid Feb and seems to be primarily
> >blocked on the fact that it is not an official Debian port yet. If it is
> >simply an issue of mirror space then why isn't one of the many unused
> >archs dropped, or preferrably the rsync script modified? As can be seen
> >by popcon almost all users use i386 currently. By the end of 2005 nearly
> >all new desktops will be based on amd64.[1] Which very likely will be
> >
> >
> I have never said anything about adding new architectures, except for my
> dislike of adding things like "i686" or "k7" ports just because of a few
> people that think it will run significantly faster than on i386
> optimized software. This time I must agree with Chris though. Debian
> *needs* to support amd64, not as a subarch of i386, but a port on its
> own.[1] Amd64 is the *first* mainstream 64-bit architecture[2].
> Personally, it would be a shame if Amd64 was blocked simply by the lack
> of mirror space[3]. It might also reflect poorly if Microsoft supports
> this new arch before open source project like Debian.
I agree, and I think we should try to get all issues resolved
as quickly as possible that currently keep the AMD64 port(s)
from beeing added as ports and added to the Debian infrastructure
(ftp server, autobuilders etc).
We actually have TWO AMD64 ports:
bi-arch ie. can run 64 and 32 bit binaries
pure ie. only runs 64 bit binaries
The pure 64bit port is the easy one, that is ready to be added to
the ftp server.
The bi-arch is the tricky (but even more important) one, because
for this one some of the Debian infrastructure (apt, dpkg etc.)
and probably most of the packages must be amended to properly
support bi-arch ports where we have two different versions
(64/32bit) of the same libraries and sometimes also binaries
installed, which for example causes problems with files that
would be shared by both packages for example in /usr/share and /etc.
The thing is there is unfortunately a lot of legacy & commercial
software around that people want/have to use that are not available
in source and thus can not be ported to a native AMD64 port.
For the next couple of years (hopefully not more then 10) we will
definitely need the biarch AMD64 until all of the applications
that people need will have migrated and the 32bit apps that people
use will wither.
For all that are now starting to yell, just think about how long
it took M$ to get rid of all the 16bit legacy software.
It will hopefully take the Linux comunity not as long as it
took Microsoft, but it is (still) the yardstick we're measured
against.
Cheers
Mike
Reply to: