[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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. 


Reply to: