* Raul Miller (moth@debian.org) wrote: > The most likely reason someone would pick the AMD64 architecture over > the PowerPC architecture is that AMD64 can natively run I386 binaries. That's quite an assumption you're making there. One that I, personally, seriously doubt is accurate considering most of the people I know w/ AMD64's (including myself) didn't buy it because it can run I386 binaries. > What you seem to be saying here (and I must admit that I've not tried > to install the current debian amd64 system) is that you want Debian to > go with some vaporware emulation capability, instead of providing that > native support. Providing that 'native' support for I386 isn't an option for sarge. Everyone knows that. If it was, we'd be doing it and sarge would be released in 2006 at best. That does NOT provide justification to not support AMD64 at *all*. > If we're going for vaporware, why not just go for the vaporware > filesystem shim which makes /lib and /lib32 appear as /lib64 and /lib > for 32 bit binaries? That way, you could claim LSB compliance, too -- > at least for 32 bit binaries. > > Vaporware can do anything. There are quite a few very happy people running Debian/amd64 systems. They're not interested in closely-integrated I386 support, they would, however like *some* support for what they're currently running. > Anyways, vaporware or not, please realise that "my 32 bit binaries won't > work" will be a significant issue for at least some of the people who > would want to install a Debian amd64 system. And treatment of that > issue would basically be the same as the outcome in the current situation: Yes, it will be a significant issue for some people. That's not a justification to not support the architecture at all because for alot of other people the support Debian has for AMD64 will be more than sufficient. > people install some other distribution, instead -- maybe with Debian > in some chroot cage so they can play around with Debian. But making a > chroot cage transparent to something like KDE or Gnome isn't completely > trivial (the phrase "inelegant" comes to mind, for some of the obvious > approaches). The *reality* is that KDE and Gnome aren't the things people are going to need chroot'd, it's things like Oracle (though I've heard even they have an AMD64 version now, though I've heard nothing of a PowerPC one), commercial compilers and other closed-source/binary things. > Of course, Debian in chroot is currently doable (it'll be i386 Debian, > which isn't glamorous, but should at least be fairly stable). Right, so you'd be able to run AMD64 Debian and i386 Debian. What you're proposing is that we only offer i386 Debian. How is that better? > And, of course, when someone running a Debian hosted in some other > OS system hits a low level bug, they're going to not be sure which OS > it's a bug in, so might be reluctant to file a report on this issue. Somehow I seriously doubt this will be the problem you make it out to be. There's only one kernel in that environment, and it's the same Debian, and it's pretty clear if you're running in a chroot or not to most people. Additionally, other people on i386 native systems could try to reproduce the bug, etc. > > The current mirroring system can hardly be considered a hack. There's > > mumblings about space restrictions, but that's really in the people > > who set up the mirror system's bailwick. > > Is this a claim that you're willing to wait for them to solve that > problem? I'm sure it's been pointed out before, but if the only issue is the mirror space then, yes, we're willing to wait for that to be solved. We might try to encourage dropping other architectures if the time frame for the space issue to be solved is excessive. At least that would be an issue we could focus on though. As it is we *don't* know what the issues are, or if those are the only ones. I don't mean to ask people to predict the future either, we'll understand if other issues come up down the road, but let's get the existing questions answered at least. Stephen
Attachment:
signature.asc
Description: Digital signature