Re: When will amd64 be allowed in sid?
Michael Neuffer <neuffer@neuffer.info> writes:
> 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.
SuSe and RH are not supporting 32bit amd64 above the very rudimentary
ability to run stuff. So there is a realy big community thats going to
push commercial programs to be 64bit.
If other distributions had a multiarch support as Debians multiarch
tries to be that would be different. This way its more a nice feature
for amd64 that is more important for mips64, sparc64, ppc64, s390x.
> 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.
MfG
Goswin
Reply to: