Re: -= PROPOSAL =- Release sarge with amd64
Raul Miller <moth@debian.org> writes:
>> 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".
That is the plan and the current implementation. As such pure64 has
succeeded and fullfilled its expectations.
There is no and never will be a transition plan from i386 to
amd64. That is just not possible. You can't replace dpkg since then it
lacks its libc and you can't replace libc since then dpkg lacks the
old one. And so on for every other essential package.
The only possible transition is from arch X to multiarch which is for
sarge+1 earliest.
>> 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.
And there we disagree. Pure64 is as usefull as any !i386 port, more
so. That it doesn't support the full range possible doesn't make it
less ready.
>> > 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.
There is no upgrade path as you speak of. Same as you can't update
i386 to mips or sparc. With pure64 amd64 is an arch on its own. No
relations to i386 all that we support (other than ia32-libs).
>> > 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.
Amd64 is a new arch. When multiarch comes along it will introduce
i386 as extra arch for amd64 same as it will add amd64 to i386, s390x
to s390, mips64 to mips, ...
We have thought about the upgrade path from uniarch to multiarch a lot
and there is nothing we found in pure64 that is not already present in
all the other archs. So pure64 doesn't put us anymore into a corner
than we already are.
>> > 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?
Maybe he ment the amd64 team?
> 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.
Otherwise the upgrade path would be closed off or greatly complicated.
Luckily the only thing that realy cares about /lib* is the ld.so and
gcc (to set the ld.so rpath and name). The rest is accessed through
that.
> But you'd still need to migrate to multiarch before you could migrate
> to a 64/32 bit system.
That is the only way. But the transition can happen on a package by
package basis. dpkg and apt can handle that without problems through
the normal Depends + the multiarch flag in control.
> 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.
Correct. Hence pure64 doesn't make the transition more difficult.
>> 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.
/lib64 requires at least 2000 source packages to be changed. For the
details on those numbers see the biarch proposal discussions.
By changed I mean the upstream source (configure scripts mainly) but
also the debian/* files.
>> > 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).
First: That will happen anyway. gcc-3.4 is comming and amd64 will
change over to 3.4 as soon as possible. At some point build-essential
will just Depend on newer toolchain versions and the buildds get
updated. It takes some coordination but its hardly uncommon.
Secondly: Not neccessarily. With multiarch support the gcc-default
package can be patched to call /usr/lib/gcc-lib/i486-linux/3.3.3/* or
/usr/lib/gcc-lib/amd64-linux/3.3.3/* depending on the uname and
flags. Multiarch systems would have the i386 and amd64 gcc installed.
>> > > 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.]
You should certainly retry. You are the first reporting this.
>> > > > 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.
Its pending upload which makes it a non issue.
>> > [*] 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.
One doesn't change the other. Changing lib -> lib64 is a lot of
work and not possible with sarge pending.
It also changes nothing for users of pure64. Both lib and lib64 work
equally well under pure64.
>> 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.
About 2000 extra packages with files moved from existing packages into
them. And now consider base being frozen. At the stage sarge is its
impossible.
> [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.]
Violates policy. Priorities must match with the Depends.
>> > > 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.]
Its one entry in your etc/fstab. Doesn't get more work for more 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.
As you will but the only think you currently need in there is the
ld.so (at least as link).
>> > 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.
Its not an issue at all. As soon as amd64 is added to sid and packages
are uploaded they must have buildable sources. dpkg not having amd64
in its archtable is a simple bug of one (very essential package) but
nothing relevant for the decision.
If fixing the minor bug in dpkg where impossible or no patch available
you could make an issue. But as it is thats just stalling.
>> 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.
For one package.
>> > 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.
What the pure64 people said is that we don't even want to support
32/64 bit.
We acknowledge the possibility and keep all possible ways open to add
it at a later time (sarge+1 with multiarch) but for now we realy don't
care. In that we are pretty much in the same boat as powerpc, sparc,
mips, mipsel and s390. The uncommon arch is not realy supported.
MfG
Goswin
Reply to: