* Goswin von Brederlow (brederlo@informatik.uni-tuebingen.de) wrote: > Stephen Frost <sfrost@snowman.net> writes: > > 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). Alright, then there's no point discussing it if we're agreed on that point. > > 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. I don't see this as a very good option, personally. I'd expect the number of -common packages to increase dramatically and would think there's a better solution. > > > >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. > > 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. I said 'those' archs, not all archs. We don't need to include archs which don't have 64/32bit dual support unless we start getting into the discussion (again) of supporting optimizations as subarchs (ie: 486, 586, 686, etc). Stephen
Attachment:
signature.asc
Description: Digital signature