Re: -= PROPOSAL =- Release sarge with amd64
Raul Miller <moth@debian.org> writes:
> [[Note, I'm a bit punchy right now, I'm still at work from friday (two
> power outages and some last minute schema changes that are acting up.
> I believe I'm coherent, but who knows if I'll believe that tomorrow.]]
>
>> > Let me ask that question a different way: what's the sequence of events
>> > leading up to the point where dpkg-buildpackage -a works?
>
> On Sat, Jul 17, 2004 at 02:08:09PM +0200, Goswin von Brederlow wrote:
>> You can go too ways. Build a biarch capable toolchain or build two
>> seperate toolchains that are multarch capable. Since we have a biarch
>> toolchain you might want to start there.
>
> What are the benefits of n-arch (n>1), and how important are they?
>
> Consumer of n-arch are people who have some kind of need for a mixed
> system:
>
> [a] Interim for a 64 bit system where not everything has been ported
> [b] People upgrading a system from 32 bits after replacing mobo and kernel
> [c] developers targetting multiple architecures.
>
> [a] and [b] don't need multiple instances of any binaries other than
> ld.so, they do need multiple instances of libs.
>
> [c] needs multiple instances of the binutils/gcc toolchain, in addition
> to libraries. (Also of interest are whatever is being developed, but
> the developer is in complete control there.)
>
> Does that sound right?
No.
[d] multiarch systems where each arch has advantages over the others
Normaly (afaik all but amd64) the 32bit part of a 32/64 bit system is
faster because the code and data segments are smaller (better cache
use, less data transfers).
So why not have everything 32bit? 64bit offers a larger address space
allowing for pplication with >4Gb footprint.
For most multiarch archs in debian the main system will stay 32bit
while only a very limited amount of packages will need 64bit versions
too (like mysql, postgresql) and all Depends for them.
[e] systems where software is not (and will not) be awailable for the
prefered arch
An example would be powerpc with qemu. There is a lot of software that
just isn't available for powerpc but only for i386. Having a
powerpc/i386 multiarch system makes sense for those.
Same for an ia64/i386 multiarch system. You still might want to play
lokigames on your ia64 system.
>> The next step is to get the dpkg-dev tools to change their output and
>> behaviour according to the -a option used in dpkg-buildpackage.
>> Currently the -a option has only a very limited effect. But maybe
>> -a<arch> is not the right way to build packages, there a different
>> ways.
>
> What about uniarch vs. multiarch? Multiarch isn't going to let gcc-3.x be
> installed where uniarch currently puts it. So doesn't the gcc toolchain
> need some work too?
gcc already uses /usr/lib/gcc-lib/i486-linux/3.3.3/ for nearly all its
stuff. gcc also already has biarch support. The changes for multiarch
are realy minor.
> Frankly, I think I'd leave the dpkg aspects alone till after I had hand
> built some multiarch packages. It's possible to emulate dpkg using basic
> tools like ar and vi, and you'll need some test packages to test against.
And you can build packages in an i386 chroot and pure64 chroot
respectively to get packages for both archs and then test them in a
multiarch chroot.
> But what I'm really concerned about is this: You've given up on biarch,
> because it's too much work for too little gain. But biarch can coexist
> with uniarch (and that's what most of the work is about).
No. biarch needs tons of extra changes on top of what multiarch
needs. All that package renaming stuff.
Multiarch is more made to coexist with uniarch.
> I don't see how multiarch can coexist with uniarch. Or rather, it seems
> like uniarch has to be replaced with multiarch before multiarch can be
> of any use.
>
> Am I wrong about that?
Yes and no. You can have a multiarch system with just one arch (thats
where you start of from). Also apart from needing a multiarch dpkg
every package says in the control file if its multiarch or not. You
don't have to replace all of uniarch before you can use multiarch.
Say we have a multiarch base system done (and just that).
That means we can install the uniarch make:amd64 or make:i386 since
make only depends on the libc (which we have for both archs).
But if you install the uniarch reportbug:amd64 it will need a
multiarch python2.3 or an uniarch python2.3:amd64. If an uniarch
python2.3:i386 is installed it needs to be purged before an uniarch
python2.3:amd64 can be installed.
Multiarch and uniarch packages can coexist but the usuability of
uniarch packages under multiarch is limited. They only work for the
right arch even if they are not libraries. For the core packages you
run into conflicts instantly restricting you to uniarch. But thats a
matter of porting more packages.
> If that's where we're going, aren't you going to need quite a bit of
> cooperation and work from the project as a whole? Otherwise, you're just
yes. Lots of it.
> moving libraries around, which makes the whole bin/ aspect of multiarch
> moot (you'll only be able to have one architecture's implementation of
> any specific executable at a time).
Multiarch uses a flag in the control file to seperate things that must
be installed for the right arch and can be installed for multiple
archs at the same time (like libraries) and things where the exact
arch doesn't matter (like binaries).
So you can install libc6:i386 and libc6:amd64 and you need the i386
one for i386 debs and the amd64 for amd64 debs.
But you can only install one of make:i386 or make:amd64. But any one
of them will suffice for a Depends:make.
Or do you see any point in having two makes installed?
>> An alternative to the -a option would be using "linux32", which turns
>> the i686 uname emulation on. Linux64 reverts that. dpkg-buildpackage,
>> dpkg-deb, dpkg-gencontrol, ... should probably be made aware of the
>> uname and change their output accordingly.
>
> But what will they do for these cases? Is dpkg just managing dependencies
> for the case where more than one architecture's packages are installed?
> Is there any need for dual-install beyond important shared libraries?
Only libs and -dev packages are suposed to be dual installable. There
might be a few exceptions but overall its just libs.
>> That would be easier to achive since the -a option would have to be
>> passed through debian/rules to any dpkg-architecture or dpkg
>> --print-architecture calls somehow. The uname emulation is passed on
>> to children automatically.
>
> By uname emulation, I'm guessing you mean making sure that a uname
> that answers things the right way is at the head of $PATH?
mrvn@dual:~% uname -m
x86_64
mrvn@dual:~% linux32 uname -m
i686
Doesn't do anything else I think.
>> So now we have a toolchain able to produce 32 bit and 64 bit binaries
>> and a way to tell packages to build for 32bit or 64bit.
>>
>> Was that what you asked?
>
> Not really. You're totally focussing on the needs of debian developers,
> and I'm trying to understand the system itself.
Well, for that I refer you to the multiarch proposal.
>> The current state of multiarch can probably be described as
>> deciding, testing and implementing how this is going to work exactly,
>> what tools to modify in what ways to best achive multiarch
>> capabilities.
>
> If the concepts are that up in the air, there's no way that you
> can meaningfully assert that it will involve less work than biarch.
> Those kind of assertions are like claiming that 1+x < 2 when you don't
> know what x is.
The biarch was nearly as much in the air as multiarch is. The amount
of work estimates are based on the amount of changes needed for the
package names, the depend/build-depends and the placement of libs.
The placement of libs is the same for biarch and multiarch but the
other two things are greatly reduced for multiarch. Multiarch was
designed with the problems encountered in biarch in mind and several
large problems have been avoided.
> I'll agree that the part of multiarch which is known involves a relatively
> small amount of work, but without a complete design that doesn't really
> mean anything.
>
> But until the specifics have been nailed down, it's too easy to seem
> sensible saying both A and B, when A contradicts B at a low level.
You are lacking any experince porting to biarch or multiarch and its
hard to make someone see the fine details without going through it at
least once. That is a big problem in arguing about it.
People have ported packages to biarch and multiarch by hand, meaning
changing the configure call, the Makefile, the rules file or whatever
else was needed. We know how to do that change by hand but ot yet how
to make tools do most of the work for us.
>> We know how we want the debs to look like at the end but very little
>> on how to get them there has been finalized yet.
>
> Maybe you could explain how you want the debs to look like -- in
> particular, do you expect that sid is going to have to replace /usr/bin
> with /usr/i486-linux/bin and /usr/amd64-linux/bin/?
No, the aim is just for lib and, where needed, include. The aim is
also to do as much as possible through moving files in the debs
without large source changes. It could be someone comes up with a
great way to write a dh_libs that will usually do all the multiarch
stuff. Things like that would make porting of a lot of packages trivial.
>> > Or do you expect that -a has to work before any other multiarch work can
>> > be done?
>>
>> You don't need to be able to build packages for multiple architectures
>> to work on multiarch. As said before multiarch will change all archs
>> to a straight forward unique lib path (${prefix}/lib/`gcc -dumpmachine/).
>
> If multiarch only deals with lib paths, how will you be managing
> multiple gccs? Don't you get stuck with the things you claim you're
> trying to avoid from biarch?
Best solution for gcc in my opinion is to completly move gcc into the
/usr/lib/gcc-lib/i486-linux/3.3.3 directory and to port gcc-defaults (the
/usr/bin/gcc binary) to pick the right gcc for the currently active
arch.
As an example the gcc-defaults package for biarch amd64 did check the
uname and did add a "-m32" or "-m64" to the options if there wasn't
already one.
>> Nothing prevents you from porting packages to multiarch on m68k for
>> example.
>
> But I need to know why someone would want to before I can understand
> what that means. [If the design were complete, I could look at the
> design for those answers, but it's not.]
>
>> The first packages that need to be ported are glibc, binutils and gcc.
>
> Is there any reason these couldn't be ported before dpkg? I can manually
> build .deb files from a directory tree if I have to. Manually build
> raw elf binaries from sources is quite a bit more work.
You can build them with the existing dpkg. Thats what people are
already doing for multiarch.
Installing them (for the non native arch) will need --force-arch
unless you have a multiarch capable dpkg. But thats nothing that
should stop you.
>
> Thanks,
>
> --
> Raul
MfG
Goswin
Reply to: