Re: Upcoming Debian multiarch support (amd64, sparc64, s390x, mips64) [affects sarge slightly]

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Stephen Frost <sfrost@snowman.net> writes:

> * Goswin von Brederlow (brederlo@informatik.uni-tuebingen.de) wrote:
> > Do you realy thing ls will run any faster in 64 bit? Well, ok, ls is
> > 64 bit already.
> > 
> > But most applications aren't cpu bound at all. Most users wouldn't
> > mind or might even want a 64bit only system but need they don't.
> 
> Need?  Who defines what people need?  No one *needs* an amd64 port, just
> use i386 on amd64, works just fine, right?  It can even use the loads of
> memory you put into the system, so long as it's not one application that

Which might be what the user needs. One killer programm eating up all
the memory.

> needs it all.  I can tell you that *this* user needs a 64bit system,
> including a 64bit ls which will actually probably make it more
> *efficient* thanks to faster handling of 64bit data types and the

Most of the time of ls is spend in seeking or going through the
kernels caches. No amount of efficiency in the ls binary is making a
noticeable difference there. And there are many programs in debian for
which the same can be said. Gaining that extra 1% speed you _might_
get from a 64bit version of something is realy not enough to warant
"need". Otherwise where is debian-i686, which is noticeably faster for
a quite a lot of things.

> additional registers.  Debian *needs* to support an amd64 system which
> is purely 64bit, through multiarch or a native system.  If we're not
> going to do that then we might as well forget supporting the
> architecture at all.

Thats the plan eventually, apart from things noone wants (unpopular or
buggy packages) or can't fix (dosemu, wine, mplayer+win32 codecs,
non-free).

> I'm not interested in a half-ass amd64 system.
> 
> > Getting everything 64bit will be a big problem with non-free.
> 
> One of the main *reasons* for multiarch is so that we can still support
> non-free crap and commercial crap while the rest of the system is 64bit.
> Obviously there are situations where it's useful to provide 32bit
> libraries to support these applications, that doesn't mean we should
> avoid allowing our users to have pure 64bit systems if they don't have
> non-free or commercial things which require 32bit libraries.

Thats why I'm for splitting every lib package into lib, lib-common,
lib-dev, lib-dev-common (where -common is needed) instead of having
the amd64 versions depend on the i386 versions for common files.
 
> > >From what I hear IA64 has no i386 compatibility, just some emulation
> > (which of cause is slow). I didn't include IA64 (or ppc64) because
> > noone from that port has shown intrest in the multiarch stuff till
> > now.
> 
> In this sense we need to be consistent across architectures so
> regardless of their interest it will affect them and therefore those
> archs should be included in the discussion.
> 
> 	Stephen

Should we include m68k, arm, alpha too?  Well, for alpha you can make
the case with True64 32 bit binaries (like Netscape was). But the
other archs should not be affected at all by any change. Not even
i386, sparc, mips, s390 should be affected, since then we would loose
compatibility to existing packages.

But enough people of each arch should be subscribed here and if not
its their fault.

MfG
        Goswin