* Russ Allbery (r...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
