Bug#535645: Wrongfull removal of ia32-libs-tools
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/
slangasek@ubuntu.com vorlon@debian.org
Reply to: