Hi, just writing this from the top of my had to be used by anyone writing this up nicely later.
Martin Michlmayr <[EMAIL PROTECTED]> writes: > * Tollef Fog Heen <[EMAIL PROTECTED]> [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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]