Bug#535645: Wrongfull removal of ia32-libs-tools
* Russ Allbery (rra@debian.org) [090809 21:49]:
> Hard to do that in debhelper. debhelper doesn't introduce brand-new
> fields in debian/control; it just uses substvars. cdbs could if run in
> the mode that regenerates debian/control, but of course that's not
> automatic.
>
> Now, if the maintainer added the Conflicts field with the substvar, then
> yes, but it sounded like Steve doesn't think even that should be needed in
> most cases?
I have a few ugly ideas how to do it automatic in both cases even
without touching debian/control, but I agree that's not one should be
proud about.
It seems to me the question on ia32-libs-tools boils down to:
What is the "right" approach about going multiarch?
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).
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.
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.
A few more (not so) random mails in that context:
http://lists.debian.org/debian-devel/2009/07/msg00093.html
http://lists.debian.org/debian-devel/2009/07/msg00060.html -
ftp-masters on removal
http://lists.debian.org/debian-devel/2009/07/msg00120.html
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"
and "does ia32-libs-tools make the transition way harder" is
unanswered, I tend to consider that the correct decision for now was
to remove ia32-libs-tools, and - in case it is ensured it doesn't make
the multiarch life unnecessary hard - then to allow it to reenter
Debian as soon as that's ensured.
Cheers,
Andi
Reply to: