Re: -= PROPOSAL =- Release sarge with amd64
Raul Miller <moth@debian.org> writes:
> 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 files reside in lib/ so dpkg will show them there but binaries are
not aware where a lib is, they ask ld.so to find it (so to speak). If
you build debs that have libs somewhere else and configure ld.so.conf
for it the same binaries will still work.
So changing the location of a lib just means installing a new deb.
>> 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.
No. There never will be a biarch amd64 unless you pick up the pices
and make one.
>> 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.
The plan is to release amd64 on its own and then, at some later time
(sarge+1) merge i386 and amd64 support through multiarch to be
coinstallable. Same way s390 and s390x gets merged or powerpc and
powerpc64, except that s390x has maybe 15 debs and amd64 has 15K.
>> > [*] 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.
You still need build-essential to build anything.
You don't need dpkg sources to build something.
>> > [*] 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.
Think about /usr/share/doc/package/copyright. libc6_i386.deb and
libc6_amd64.deb have to have that file but then dpkg complains.
Mutliarch is fun. But its all in the proposal (or not yet solved at
all).
>> 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.
If you like a challenge tell us why sbuild works for all packages
except for zsh/zsh-beta. For those two the build looks up in state
"T". Using debuild in the same chroot works perfectly.
>> > 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?
you mount the 64bit / inside the 32bit chroot (thus creating a circle)
and then configure the mime.type to use dchroot to change back into
64bit.
Or you install all the libs needed for OO in /emul/ and run it without
chroot. Since ia64 and qemu have the same problems they probably have
some FAQ or dpkg wrapper script to install ia32 debs. The same applies
for amd64.
>> 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.
The plan is as follows:
i386 amd64 sarge/sid now
\ /
\ /
_\| |/_
multiarch
/ \
/ \
|/_ _\|
multiarch i386 multiarch i386/amd64 sarge+1
>> > 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.
As a sidenote: People that can spend tens of thousands of dollars on
software usually have the time to setup a chroot properly. :)
> 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.
Absolutely. And the overall opinion goes towards that the transition
will be complete before sarge+1 comes out for all relevant
purposes. Hence the don't care attitude towards 32bit, it will solve
itself before debian can solve it. :)
MfG
Goswin
Reply to: