Re: Edge and multi-arch
Hi,
just writing this from the top of my had to be used by anyone writing
this up nicely later.
Martin Michlmayr <tbm@cyrius.com> writes:
> * Tollef Fog Heen <tfheen@err.no> [2005-03-14 13:10]:
>> | I have yet to see a proposal how to do multiarch in the right way.
>> What is lacking in the proposals out there?
>
> The following is what I (as DPL) sent to the release people in January
> to get them to discuss these issues. I didn't post this to a list
> because what I wrote is kinda rough and I wanted the release people to
> clarify and post it. Since this hasn't happened yet, I might just as
> well post my original message. But please note that some important
> things might be missing in it.
>
>
> Basically, there has been a lot of discussions about multi-arch and
> some people seem to think that after sarge we'll _obviously_ move to
> multi-arch. Well, this is not so obvious to me. In particular, I see
> no consensus among ftpmaster/archive people, release people, toolchain
> people, porters, and basically everyone else that this is the way to
> go. If we decide to go with multi-arch, we need:
>
> - agreement of all these people
Ftpmaster has to allow new archs: amd64, ppc64, mips64, mipsel64,
sparc64, s390x. Amd64 seems to be a done deal. Mips, mipsel, sparc and
s390 are no release candidates for etch so who cares. :) The only
question remaining is ppc64. Will ppc be in etch? Will ppc64 be added
to scc or the main archs?
Release has to allow the new archs for a release. Same deal, amd64
seems a done deal, ppc64 a big questionmark, the rest aren't in etch.
The toolchain in sarge is already 99.9% multiarch. Only question there
is changes in the number of packages to allow installing a 32bit only
or 64bit only deb instead of the 32/64 biarch debs in sarge. With the
current 32/64bit support only the Depends need a slight change when
ia32-libs/amd64-libs becomes multiarch packaged.
Porters. Hmm, the amd64 porters have done most of the multiarch stuff
and pushed for the toolchain in sarge. PPC64 porters seem to agree
with us. As for the rest non release archs that don't even exist yet no
porter has shown up and complained yet. :)
As for every one else only maintainers of base packages are needed to
accept patches for multiarch support. Those are mostly splitting debs
or adding one line to the debian/control stanza and not changes to the
upstream source.
> - a _clear_ plan about this migration (and have this plan before
> sarge is out), including a clear timeplan (announcement on day X,
> maintainers have Y months to upload, if they don't do it in Y
> months, we'll have a time of Z people who'll NMU the packages by
> G).
Add patches for multiarch to all base packages the day amd64 is added
to the archive. Maintainers get 7 days (as per NMU policy!) before a
porter NMU to experimental is done. We are only talking about 161 debs
(way less sources) and any non lib needs just a one line fix in
debian/control. Wait for the buildd to build them. Done.
So say 2 weeks after amd64 is added multiarch will be in experimental
all ready for an release. Say 1-2 month to test it widely and then
move it to sid. Any other debs getting ported to multiarch is just a
bonus, not a necessity.
Too radical? One can still dream.
> - a proof of concept (this may exist already)
Done twice already. Tollef is no implementing a release quality
version.
We might have a fully usable i386/amd64 multiarch base archive on
alioth before sarge comes out depending on how long sarge takes.
> - agreement with some upstream LSB people that it's a good idea for
> Debian to pioneer this in the hope that others will follow suite
> (rather than a way of Debian to make itself incompatible with
> the rest of the world). [Chris Yeoh and taggart are the people
> to talk to.]
Since multiarch is designed to be ported package by package
compatibility with the old debs must be maintained. That also means
any 3rd party software should continue to work (baring broken
rpaths). LSB compatibility isn't a big deal. A matter of the lsb
package adding a few links. Changing the LSB and FHS biarch proposals
to something sane remains to be done though.
I didn't realy follow any of the discussions with upstream but what I
read on a per chance basis sounded encouraging to our proposal of
using [/usr]/lib/<gcc arch-os pair>/ instead of lib|lib32|lib64
as previously proposed.
> There may be a few other things missing, but basically the multi-arch
> people have to show a clear plan _now_ how and why this migration is
> supposed to happen.
>
> Can one of you take what I said just, put this in some more coherent
> form and post it to -devel?
>
>
> --
> Martin Michlmayr
> http://www.cyrius.com/
Hope that helps someone to write this up nicely.
MfG
Goswin
Reply to: