Re: -= PROPOSAL =- Release sarge with amd64
On Fri, Jul 16, 2004 at 05:16:10AM +0200, Goswin von Brederlow wrote:
> 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.
Which means it's probably not going to change. This is an easy choice
up through system install time, but a tough one upgrade time.
> No, the only thing referencing lib or lib64 is the ld.so.
I thought you were building packages which referenced /lib,
because the effort of changing them was too high? In other
words, that dpkg -L would list files in that location.
> 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.
Except, amd64 should be a biarch -> multiarch transition, not a
uniarch -> multiarch transition.
> 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>/.
As an aside, I thought the dest was <arch>-<kernel>/lib/?
> > 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.
It might be that the only reason I have not is that I've mis-understood
the current state of affairs. I'm still trying to understand your
plans.
> > [*] amd64 binaries can't be built from the sources in main, and
>
> Because there is no amd64 in main.
There are no amd64 binaries in main. I'm talking about sources.
> > [*] 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.
I'm glad you told me about how ld.so supports the transition.
I'd forgotten about ld.so's role at execution time and hadn't realized
how it would help.
I'm still concerned about the physical aspects of managing the files.
> 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.
I'll check it out.
> > 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.
The buildd aspect helps. I still think this one needs more testing.
> > 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).
Ok, let's consider the howto for a moment.
Let's say I'm installing something like openoffice, but I want the
32 bit /etc/mime.types to use my 64 bit gimp when displaying images.
How do I configure this?
> 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.
Ok. Maybe if we can put to rest the 32->64 bit transition planning
issues, ftp-master will speak up on this other one.
> > 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?
Not completely. But your explanation did clear some things up for me.
> 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.
Contrast "eventually, I won't need this app anymore because I'll be
using a 64 bit version" and "there's a 64 bit version of this app, but
it costs tens of thousands of dollars, so I'm using the 32 bit version --
despite its lameness -- for now."
Both statements can be true.
The value of 32 bit support is at transition time, and that's decided
on a program by program (or package by package) basis for each user.
--
Raul
Reply to: