* Raul Miller (moth@debian.org) wrote: > On Thu, Jul 15, 2004 at 08:33:23AM -0400, Stephen Frost wrote: > > 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. > > It is an assumption. It's based on some simple observations > on how the marketplace has treated various 64 bit > architectures. Right, my observation is from talking with real people who really bought amd64 systems and who really would like to run Debian on their systems. > That said, the accuracy of this assumption also depends on the group > of people you apply it to. I think it's safe to say that it's not > likely to be accurate for any of the current debian amd64 porters. No, and also not likely to be true for most people who run *Debian*, or most people who have asked about Debian's amd64 support on the mailing lists. Debian supporting amd64 isn't likely to make a bunch of Windows users jump ship to Debian and then want to run all their Windows 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. > > Sure it is -- that's the i386 port. [Yeah, but that doesn't take > advantage of the amd64 architecture... hold that thought.] No, I said *that* native support, as in, the ability to run both on amd64. Try to keep things straight. > > 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*. > > The question is, what's the upgrade path to an amd64 system which supports > 32 bit code? Is that going to be easier from i386 than from amd64? > Without a really solid reason to believe that the current amd64 would > make that easier than i386, it's kinda hard to rationalize squeezing > amd64 into sarge. It's not all about the upgrade path, sorry. Additionally, the reality is that, guess what, it'd probably be *easier* to move to multiarch from amd64 on amd64 than from i386. We're going to be dealing with the i386 to multiarch transistion, at least this way it'll look reasonably the same on all the platforms as opposted to special on amd64 because you also have to change the base architecture type from amd64 to i386. It's certainly very unlikely to be harder. Oh, yeah, and guess what else that means? Debian won't support amd64 in the next release, which will make alot of people unhappy. > If we release an amd64 in sarge, we're committing to supporting it. Yes, which is what people want from Debian, a supported amd64 architecture. It's what our *users* who have amd64 systems would like to see. > If the current port paints us into a corner, that's a good reason to > not start supporting it yet. I honestly just don't see this as the case. > It seems to me that migrating from a 64 bit /lib would require several > steps: > > First, you'd have to build a system which references /lib64 instead > of /lib, once you've upgraded to that system you could then get rid of > /lib and replace it with a 32 bit /lib/. Which means we'd be ready take > advantage of amd64 native support for i386 binaries sometime around 2010. > Maybe. Uh, have you *read* the multiarch proposal? Do you understand it? Do you realize that /lib64 is *not* where we're going? It seems clear to me that you havn't and aren't in any position to comment sanely on how hard or easy it will be to move to it. > That's not a very exciting prospect to consider if the reason we're > trying to get amd64 in sarge is that not offering the support for the > architecture that other distributions do would make us a "laughingstock". The reason we're trying to get amd64 into sarge is because our users would like to be able to install a Debian which takes advantage of the nice shiny new system they bought. The ones we've run into so far seem pretty pleased with pure64. Would they like it if we had everything sorted out and taken care of already so they could run both 32bit and 64bit applications? Sure. But given a choice between 32bit only and 64bit only, I expect pretty much all of them will go with 64bit, and be much happier than if their only option was 32bit. > > 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. > > You mean more support than they're currently getting, I presume? Yes, of course, support as in supported as a Debian stable arch. > I can guarantee you'd get more support for a 64/32 bit system than a > pure 64 bit system. [As in, I'd contribute.] Then go help w/ multiarch! We could use some help, I wrote some (crappy) gcc patches for it that could use some working on (esp. the libgcc1 issue and similar). Tollef might be able to use some help on glibc, there's people working on apt/dpkg, etc. Certainly lots of work left, and once the base packages are done we'll need help going through and fixing all of the libraries too. > > > 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. > > Not in and of itself, certainly. The reasons to keep it out of main > include: > > [*] amd64 binaries can't be built from the sources in main, and Uhhh, that's news to me. There's a relatively small set of packages that need patches but not nearly as many as you seem to be implying. Have you looked at the archive on alioth, and the set of patches there? > [*] lack of a clear upgrade path to 64/32. The upgrade path will be from non-multiarch to multiarch and it will be happening for *all* platforms, so trying to play this as an amd64 problem just is wrong and speading FUD. That upgrade will be *every* architecture, *not* just amd64. PLEASE go read the multiarch proposal and quit trying to bring up these issues that just plain don't exist and attempting to use them as justification for keeping amd64 out of sarge. > > 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. > > It's not KDE and Gnome themselves which are the issue, but applications > which people would want to run from within KDE and GNOME (or just > plain X). > > It's the integration which is painful. Uh, it's certainly possible to run X applications from within a chroot talking to the X server running on the main system. You could even set it up to run the apps from KDE/GNOME/whatever, though, sure, it wouldn't be quite as simple. It's not *that* bad and our goal is to reduce the number of things people would need to chroot as much as possible without having to change every library in Debian. You might try reading this: http://alioth.debian.org/docman/view.php/1314/21/debian-amd64-howto.html > > 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? > > Less complex upgrade path to AMD64 with 32 bit support. Not true, not true, not true. Go read about multiarch. The complexity will be there regardless. > > 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. > > I've had i386 debian running in a chroot where make didn't work because > of something icky with fork and signal handling. > > If i386 debian can get screwed up by a chroot, what makes you > think that amd64 debian would not? I don't think that it wouldn't. Certainly there may be cases where there are problems, but I fully expect them to be quite rare and certainly not worth keeping amd64 support out of Debian for. > And that's aside from problems like "ok, I've got my 64/32 > environment running X, and now I want to run a debian X app > inside a chroot cage." Right, go read the howto. > Last time I checked [two days ago], the trivial change to dpkg to support > amd64 hadn't happened. I think making sure that the debian package tools > work right for the architecture should be considered pre-requisites for > using the package system to present the rest of the packages. You're really starting to kill me here. Debian package tools work right for amd64. The ENTIRE ARCHIVE has been built for amd64. People are running it TODAY. There were/are buildd's which are updating it using a simple w-b script. The dpkg maintainers have said they'll add support for it, hell, the only reason it isn't there is because there was some discussion on what exactly the arch name was going to be (weren't you involved in that?). How can you honestly sit there and claim that we havn't made sure the debian package tools work right for the arch? It's honestly completely astounding, and very, very concerning considering your position. > And note that this is completely independent of buy-in issues, like the > future of 32 bit support (which is the issue which was raised in #248043). I don't see the future of 32bit support being raised in that thread... The only thing I saw was Joey's comment about it not being compatible w/ AMD64 on other systems, which isn't true for amd64 applications. His claim about it being 'worthless' is also rather short-sighted given how many people are running it today already, prior to it even being in Debian officially. Stephen
Attachment:
signature.asc
Description: Digital signature