Re: -= PROPOSAL =- Release sarge with amd64
Raul Miller <moth@debian.org> writes:
>> * 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:
>> > 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.
i386, amd64, sparc, mips, mipsel, powerpc, s390 are all individual
ports. When multiarch gets added all those ports will gain the ability
to install and run packages from other ports (e.g. i386 on amd64)
[assuming hardware/emulator capabilities exist of course].
For all those ports it will be identical. The same changes need to be
made and the same transitions happen.
The only thing special for amd64 is that at some point the /lib64 ->
/lib link might (or might not) be turned back into a real
directoy. But that can/will only happen if it can happen silently
without disturbance.
> 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.
No, the only thing referencing lib or lib64 is the ld.so. Because of
that existing i386 binaries work with /emul/i386-linux/lib under ia64
or amd64 already. That placement of libraries can change at any time
without even a special transition (like the c102 names). Binaries need
not be recompiled for this change.
The changes to make the uniarch -> multiarch transition go smoothly
and in one release, while applying to amd64 too, are completly
seperate to the issue and have to make the transition smoothly for
i386, ppc, s390, mips, mipsel and sparc. Amd64 is just on of the
affected archs and does in no way change the timeframe.
The change for /lib (as proposed by multiarch) is also going to happen
for all architectures regardless if the architecture supports
multiarch or if multiarch support is wanted. All architectures will
move the libs from lib/ to lib/<arch>-<kernel>/.
Only packages that have completed that transition can claim to be
multiarch capable and then they can be installed for multiple
archs. The multiarch capability will be noted in the control files and
dpkg/apt will follow that and the Depends fields to allow a package by
package transition.
Lets draw a picture of how the transtion will probably look to the
user:
(0. Some multiarch capable libs might get installed. Since no recompile
for binaries is needed that is not a problem.)
1. The user updates dpkg/apt which include multiarch support. There
might be some debconf question configuring the users preferences or
not. That remains to be seen.
2. The next time the user 'apt-get update's Packages/Sources files for
the additionaly supported ports for the users arch are downloaded and
the database files updated.
3. Any apt-get upgrade/dist-upgrade/install action from then on will
utilize the multiarch capabilities.
> 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".
Actually getting amd64 into sarge means that we will have a wide range
of packages available and ready for use with multiarch when that takes
off. Multiarch could be backported to stable and used alongside the
pure64 debs.
>> > 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.]
Then why don't you? The biarch proposal have been around longer than
pure64 and multiarch (its successor so to speak) is still there.
>> > 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
Because there is no amd64 in main. Thats a circular argument saying
'We can't add amd64 support because we have no amd64 support'.
> [*] lack of a clear upgrade path to 64/32.
That is as unclear (and not wanted for before sarge+1) as for all the
other multiarch archs. See above for some clarifications.
>> > 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.
Ia32-libs includes X and even some GTK libraries. If you need more
support we can certainly add more libs. But show us the need first.
The ia32-libs package has been used on ia64 for some time and they
didn't seem to need more libs in general.
>> > 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.
No. makes no difference at all.
>> > 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?
Because all the buildds run in chroots and most amd64 porters use
chroots. Chroots have been well tested and the remaining problems
should be very rare and jus as likely to appear on any arch.
> 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."
Then you just do it and it works or you go and read the FAQ explaining
you how to setup a chroot (which you should have done in the first
place).
>> > > 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.
Which is a chicken-egg kind problem.
If ftp-master says "we will add amd64 only when dpkg supports it" you
can be sure that the support will be there on the next dinstall run
one way or another.
As it is there is no reason to upload a new dpkg that has 0 changes to
any existing architecture. That is just a waste of buildd resources
and maintainer time. It should be clear to everyone by now that dpkg
support is fully existing and ready at a moments notice if needed.
> 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).
Which have been explained and resolved or not?
MfG
Goswin
PS: Most people don't see a future for 32bit support for amd64. Like
noone uses 16bit windows apps anymore. By the time sarge+1 comes out
you probably won't find a current application with just 32bit support.
Reply to: