Re: -= PROPOSAL =- Release sarge with amd64
> * 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.
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.
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.
> > 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.]
> 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.
If we release an amd64 in sarge, we're committing to supporting it.
If the current port paints us into a corner, that's a good reason to
not start supporting it yet.
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.
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".
> > 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.
You mean more support than they're currently getting, I presume?
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.]
> > 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
[*] lack of a clear upgrade path to 64/32.
> > 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.
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.
> > 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?
Less complex upgrade path to AMD64 with 32 bit support.
> > 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.
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?
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."
> > > 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.
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.
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).
--
Raul
Reply to: