Re: -= PROPOSAL =- Release sarge with amd64
Raul Miller <moth@debian.org> writes:
> On Wed, Jul 14, 2004 at 10:17:14PM -0800, D. Starner wrote:
>> To become LSB compliant would involve changing half the packages in
>> Debian to achieve a result to many AMD64 developers consider inelegant;
>> furthermore, a multiarch design is being created that would allow
>> us to install Linux binaries on NetBSD or Hurd, or ix86 binaries on
>> PowerPC, provided an appropriate emulator, as well as 32-bit on a
>> 64-bit system. This will require changing half the packages, but for
>> a better design. It's not a hack, it's a feature.
>
> The most likely reason someone would pick the AMD64 architecture over
> the PowerPC architecture is that AMD64 can natively run I386 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.
No, you completly misunderstood that.
Currently the LSB uses /lib, /lib32 and /lib64 to place libraries in
non conflicting places. But they still do conflict (e.g. i386-linux
and i386-kfreebsd lib, or ppc and i386 libs for qemu) or one and the
same lib has to be in different places depending on the main arch
(i.e. i386 uses /lib for ia32 while ia64 uses /lib32) and doesn't even
have a solution for tree-arch systems like mips/mipsel.
What it comes down to is: The current LSB approach
- is ugly (pollutes / and /usr namespace,...)
- does not solve all problems for multiarch
- uses different ways for the same ABI on different CPUs
- complicates supporting it needlessly
The approach thus chosen is to improve the LSB and skip implementing
the broken design and go directly to a cleaner and more elegant
complete solution.
> 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.
Instead we just chose to only actively support the amd64 LSB on amd64
since that is the only thing currently sensible. Anything else would
be vapourware.
> Or how about building the chroot cage that seems to do the equivalent, and
> debian install time. Maybe make it a package (amd64compat32). Oops, now
> you need something to automatically chroot 32 bit binaries. Well, you can
> use vaporware for that, too (at least this would be simpler vaporware).
>
> 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
>From past experiments we know they will work. We are not actively
support it or aim for it. For all we know the amd64 port is compatible
but not compliant with ia32 and amd64 LSB. Meaning stuff that relies
on the LSB will work.
> 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:
>
> 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).
Most people will have no need for any 32bit apps and those that do
usualy only need a very limited range (like one commercial
application). Making that one app work under pure64 is trivial and
even when a wider range is needed and a chroot is best the FAQ covers
how to set it up, including X transperence.
> Of course, Debian in chroot is currently doable (it'll be i386 Debian,
> which isn't glamorous, but should at least be fairly stable).
>
> 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.
> Which might mean they eventually give up on the chroot -- but at that
> point it really doesn't matter whether they have 64 bit debian in the
> chroot or 32 bit debian.
>
>> 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?
>
>> It is a little frustrating
>> that s390 and friends could join, no questions ask, but AMD64 gets
>> the third degree.
>
> I understand the frustration, but treating the people who are trying to
> help you like they're your enemies is not a good way to deal with it.
Are they?
MfG
Goswin
Reply to: