Re: Bug#535645: Wrongfull removal of ia32-libs-tools
Steve Langasek <vorlon@debian.org> writes:
> 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.
Then ia32-libs-tools will just have to move /usr/lib/i486-linx-gnu to
/usr/lib32 just like now it moves /usr/lib to /usr/lib32. If that is
required to get ia32-libs-tools back then that is hardly an obstacle.
>> 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.
Which is based on your dislike of biarch (we all hate it) and not on
ia32-libs-tools being technically harmfull. Unless you have other
reasons than the refuted "it might hinder multiarch" you have not yet
shared?
>> 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.
No they don't. Maintainers will not have to move a finger.
| 7.4 Conflicting binary packages - Conflicts
|
| When one binary package declares a conflict with another using a
| Conflicts field, dpkg will refuse to allow them to be installed on
| the system at the same time.
|
| If one package is to be installed, the other must be removed first
As I said the ia32-libs-tools generated packages will conflict with
the multiarch packages as soon as someone implements the relevant
multiarch part in dpkg. The conflicts works both ways. That will even
work if ia32-apt-get is removed while ia32-* packages are still
installed. Also a multiarch dpkg can declare a conflicts with
ia32-abi catching all packages in one go. Or conflict with ia32-abi-1
to catch all packages converted prior to it being raised.
Further as long as ia32-apt-get is used it can also insert
Conflicts/Replaces entries the other way. From the multiarch package
to the ia32-* package. That makes it easier for apt-get / apitude /
synaptic to see that it should prefer the multiarch package. Note that
the biarch packages will automatically disapear from the availabe file
when the respective multiarch package appears.
Both things are under the assumption that ia32-libs-tools itself will
not first transform packages from ia32-* (biarch) to *:i386
(multiarch) anyway. That part purely depends on timing. Will dpkg get
multiarch support first or will individual packages be multiarch fist?
Since you are focusing on apt / dpkg the ia32-libs-tools packages can
change from biarch to multiarch before any conflicts with individual
packages even arise.
So at most one maintainer will be asked to add one Conflicts to one
package, not every one. I don't see that as an undue burden.
MfG
Goswin
Reply to: