Re: -= PROPOSAL =- Release sarge with amd64
> > It is an assumption. It's based on some simple observations
> > on how the marketplace has treated various 64 bit
> > architectures.
On Thu, Jul 15, 2004 at 05:11:29PM -0400, Stephen Frost wrote:
> 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.
How many people?
> > 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.
That's a self selected group of early adopters.
> 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.
I don't care about that.
> > > > 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.
I'm running native i386 debian on an amd64 right now.
I have a good idea what you think I don't have straight, but I'm
disagreeing with you.
> > > 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.
That doesn't make upgrade path irrelevant.
> Additionally, the reality is that, guess what, it'd probably be *easier*
> to move to multiarch from amd64 on amd64 than from i386.
Maybe. I've yet to see that designed, so I'm not in a position to
comment on it.
> 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.
If you don't provide a dual 32/64 bit amd64, your transition strategy
is going to be "install it on a different partition" or "backup, wipe
and reinstall".
> Oh, yeah, and guess what else that means? Debian won't support amd64 in
> the next release, which will make alot of people unhappy.
What we have now is not ready for release.
> > 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.
I hope by "support" you don't mean "backup, wipe and reinstall" as the
upgrade path.
> > 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 might indeed be that the current port doesn't paint us into a corner --
but if that's the case, that's what I'm not seeing.
> > 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?
Are you talking about http://raw.no/debian/amd64-multiarch-2
The one that says "We are not trying to solve the issue of having
multiple applications with different ABIs installed at the same time,
so having both a i386 and an amd64 perl installed at the same time is
out of scope for this document."?
Why do you ask?
> Do you understand it? Do you realize that /lib64 is *not* where
> we're going?
By "we", do you mean everyone in debian who has agreed with the social
contract?
Note that there's nothing in the multiarch proposal which prevents the
support of 32 bit binaries compiled for /lib nor 64 bit binaries compiled
for /lib64. This is a good thing.
But you'd still need to migrate to multiarch before you could migrate
to a 64/32 bit system.
And I see nothing in the multiarch spec that makes migrating from a
/lib64+/lib system any more difficult than migrating from a /lib system.
> 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.
By "it" I presume you mean "a multiarch system".
What I don't see is any sane reason to not start out from a /lib64+/lib
system. Maybe there is one, but telling me how it's clear to you what
I have or haven't though doesn't convey any specifics to me.
> > 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.
Before we commit to supporting the port, providing 64/32 means rebuilding
the gcc toolchain. If we commit to supporting a pure64 system it becomes
a lot more complicated (for example: wait till after multiarch is ready).
> > > 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.
Ok.
> > 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.
Last time I checked, make didn't run under debian on my amd64 system
because of problems related to my chroot environment. And I don't
have enough time to go without both 32 and 64 bit support in my main
environment. Otherwise, I would be helping on this port.
[When I got the machine, I was intending to help the port along, but I
got bogged down long before I was in a position to do anything useful.]
> > > > 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?
Frankly, the only package I know about that needs to be patched is dpkg.
And that's a trivial patch which doesn't affect any compiled code.
That doesn't make it a non-issue.
It could very well be that every important package could be fixed
overnight, in which case that reason goes away. But that doesn't make
it a non-reason.
> > [*] 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.
The multiarch document I see in front of me says:
Q: What about /usr/lib64, /usr/lib and /usr/include?
A: They are kept around for historical reasons, but will go away once
they are empty at some undefined point in the future.
Which seems to indicate to me that multiarch has no problem absorbing
/lib64/. And you seem to be implying that asking for /lib64/ on amd64 is
a bad thing to ask -- if that's not what you're saying, please try again.
> 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.
I guess you want me to read:
"Renaming packages is a lot of work, and will not scale once you want
to have three or more architectures being coinstallable."
What I don't see is why this isn't doable for sarge. Ok, I'll agree
that you'll get a bunch of extra package names for the 32 bit support
stuff. And, I'll agree that those packages would be temporary and
would go away when multiarch comes out. But I'll agree to build them
myself if you'll give me a framework in which to install them.
[And, as for clean upgrade, just make the packages optional, and give
them a Conflicts: task-amd64-multiarch-upgrade or some such and they'll
be fairly easy to clear out of the way when the time comes.]
> > > 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
I agree it's possible. But it's quirky. [And, tedious, when you
have a lot of such apps.]
> > > 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.
I'll agree that multiarch is so complicated that it outweighs any of
the complexities involved in 32 bit support.
That said, I'd still want /lib and /lib64 on a multiarch system for
probably at least the next three or four debian release after sarge.
> > 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.
As long as you're not claiming that chroot is an adequate replacement
for native, I'll let this one rest.
> > 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.
I've got what is for me a simpler approach. That doesn't make this
a non-issue.
> > 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?).
Are we talking issues relevant to ftpmaster or not?
If we are, then "this patch hasn't been incorporated into main yet"
is an issue.
> 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.
That's not my claim.
My claim is that the source for those packages hasn't been uploaded
into main yet.
> > 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.
But which is true for 32 bit applications. And he very explicitly
was talking about a mixed 32/64 system.
> 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.
I read his message and see that he wants to hear about how the system will
support a 64/32 bit environment. You seem to be saying that you don't
even realize he's talking about that. And, it's true, the subsequent
posts on that bug mostly dismiss his comments.
But that just means you're talking past each other.
--
Raul
Reply to: