Andreas Barth <a...@not.so.argh.org> writes: > * 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.
As said in another mail that isn't even needed at all within the framework of ia32-libs-tools. > 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). Seems to be a big misunderstanding here. Ia32-libs-tools is not using /usr/lib/$(DEB_HOST_GNU_TYPE) and it is not going to just randomly start using /usr/lib/$(DEB_HOST_GNU_TYPE). I was talking about packages in Debian starting to use it as per the multiarch proposal: https://wiki.ubuntu.com/MultiarchSpec#Filesystem layout I believe wine is the first package that is experimenting with using that. > 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. I want to be clear here. The plan I gave is the transition plan from ia32-apt-get to multiarch. In http://lists.debian.org/debian-devel/2009/07/msg00120.html Pierre Habouzit acused me of "has no forward upgrate path to a multiarch work". Well, there is my planed path. The plan I presented was to show that ia32-apt-get will not stand in the way or hinder multiarch or place extra work on maintainers. It will, if all goes according to plan, transition to multiarch with the push of a button. I do not have a plan how Debian (esspecially with ia32-libs and ia32-libs-gtk) will transition to multiarch. But when they do then ia32-apt-get will follow. > A few more (not so) random mails in that context: > http://lists.debian.org/debian-devel/2009/07/msg00093.html Yannick was happy about ia32-apt-get because it let him do thinks he could not do before. Pierre was enraged about it. I think he was still writing about the fatefull version 18 upload that cause all the ruccus, the one where ia32-libs pulled in ia32-apt-get for the first time instead of users having to specifically install it themself. That was reverted the night before that mail so it realy is purely a users choice to install ia32-apt-get. As in any flame war emotions ran high. Please keep that in mind when reading that flame war. > http://lists.debian.org/debian-devel/2009/07/msg00060.html - > ftp-masters on removal Also about the dpkg/apt diversion and taking over ia32-libs. Or so I assumed. That mail was following the discussion on irc where Mark Hymers offered to maintain ia32-libs and I imediatly agreed and ask Joerg to remove the offending ia32-libs/ia32-libs-gtk packages, prepared the version 22 upload and filed the initial ROM bug. I assumed, maybe wrongly, that that mail was just reflecting the current status as discussed on irc so people would stop bugging ftp-master about it. I did not get any indication on irc or understood that mail in a way that Joerg ment removing all of ia32-libs-tools completly. And at the end of the mail he says: "It has mainly been written due to the fact that we have been asked by multiple people to remove ia32-libs-tools but don't want to do so until a consensus has been reached on what we're going to do to replace it." Shoudn't the packages maintainer be involved in finding a consensus? > http://lists.debian.org/debian-devel/2009/07/msg00120.html As said above my plan solves the transition to multiarch and only multiarch can solve the other point about converting packages being a hack. > 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. I think after 1 1/2 years it is a bit late for just removing the package. People have been using it for a long time and it has grown a user base. If there really is a reason why ia32-libs-tools would make the transition way harder then that obviously has to be fixed, not ignored. I think my transition plan solves this issue and will go nicely with debian adopting multiarch. Removing ia32-libs-tools just leaves all the users of it high and dry and will make transitioning to multiarch difficult for them. That is certain. Keeping ia32-libs-tools means I can work along side the multiarch developement and make the transition as smooth as possible. And as you said it is still unanswered if there is a problem at all. So one has to weigh certain problems against possible problems that can be fixed as they become clear. You know what I would prefer. MfG Goswin -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org