On Sun, Aug 09, 2009 at 10:22:14PM +0200, Andreas Barth wrote: > It seems to me the question on ia32-libs-tools boils down to:
> What is the "right" approach about going multiarch? I don't agree that this is the right question, because ia32-libs-tools is explicitly *not* part of multiarch. It's a generalization of the existing biarch kludge, and as such is the *opposite* of multiarch, notwithstanding the fact that Goswin is planning a transition path to multiarch from ia32-libs-tools. The right question is if there's a compelling reason to override the ftp master decision. The rest would constitute design work on the part of this committee, which is a) out of scope, b) a bad idea. :) > Obviously Steve disagrees with Goswin on the direct usage of > /usr/lib/$(DEB_HOST_GNU_TYPE) by packages. The same goes for the > question whether there should be a tool to automatically convert > normal packages "somehow" to pseudo-multiarch (or call that like you > want). I disagree with the direct usage of /usr/lib/<triplet> by any *biarch* package: that is, I disapprove of use of these paths by any packages whose Architecture doesn't match the triplet. Since we will soon start to see packages making legitimate use of the multiarch paths, that means none of these libraries should *ever* be cross-installed via ia32-libs-tools, or else those kludged packages will directly conflict with multiarch-enabled packages that are cross-installed. > If the transition plan is like Goswin said here, I tend to consider > removing ia32-libs-tools to be wrong. My impression on that plan is > however that there is currently next to no buy-in from > dpkg/apt-maintainers, ftp* or anyone else who should be in the loop > for major changes. Looking at debian-devel during July shows quite > many heated discussions, which is usually a sign that a plan is not > accepted by the community at large. The transition plan described is Goswin's own, not one that is the object of a larger consensus. My opinion is that the transition plan should consist of not having ia32-libs-tools anywhere near the archive. > If the transition plan is to avoid the conflicts (like put by Steve), > then the removal of ia32-libs-tools was necessary. I actually would be > interessted who is the driving that transition plan - a few names were > put up, but I haven't seen someone saying "I do it". Also the question > on buy-in should be answered here as well. To what "transition plan" are you referring here? Are you talking about multiarch? It seems so, but I'm not sure, as multiarch is not a "transition plan", it's a design for laying out packages; and one which, if done right, has so few transition requirements as to defy being called a "plan". > The situation *currently* looks to me like there is no real decision > on how to do multiarch by the Debian project. A few things are already > getting decided (like naming of field values, or splitting of binaries > from glibc, see #330735), but as long as "who is driving the > transition", "how should the package layout be after the transition" I thought this should have been clear from the mailing list discussions to date, but as it's possible that you (and other members of the TC) have overlooked something in the thread, or that I failed at making it clear, let me clarify here. I am currently driving the implementation of multiarch, in the sense that I am investing time in pushing to make it happen; this will of course not happen without agreement from affected maintainers, and I am indebted to a number of others who are doing much of the work on implementation, but in terms of taking overall responsibility for keeping multiarch moving forward, that's exactly what I've been doing since about March of this year. At present, this effort is focused on the package manager definition and implementation, as described here: https://wiki.ubuntu.com/MultiarchSpec I have actively sought input from the maintainers of the affected packages, and that spec reflects feedback from, among others: Guillem Jover (dpkg), Aurelien Jarno (glibc), Michael Vogt (apt), Hector Oron (emdebian), Tollef Fog Heen (author of various multiarch whitepapers), Colin Watson (Ubuntu), and was the subject of a roundtable at DebConf9 (video available): https://penta.debconf.org/dc9_schedule/events/395.en.html This plan does not require any changes to the division of packages compared with what's currently required by Policy, if that's what you mean by "package layout". Or, if you mean filesystem layout, that part of the design has been fixed for years. We should probably have a single good document we can refer to for this part, but I'm not currently aware of one that's available; I think some of the original papers Tollef wrote on the subject may have suffered bit rot. Even so, I'm not aware of any disputes over the target filesystem layout. > and "does ia32-libs-tools make the transition way harder" is > unanswered, It makes it harder because there will be a large number of conflicting biarch packages in the wild, which either the maintainers of each multiarch library will need to declare Conflicts with, or they will be a source of bug reports and confusion from users of this tool. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
