Andreas Barth <[email protected]> writes: > [ buy-ins snapped ] > > Now, Goswin has the choice to show a similar buy-in from core > maintainers in Debian. After private conversations I had with some, I > however doubt that this is possible.
Buy-In to do what? Should I ask core maintainers to buy-in to do nothing? Ok, I can ask the dpkg maintainers if they will "Conflicts: ia32-abi". Because that is the only thing being asked of core maintainers. > Unless proven otherwise, I tend to the following conclusions: > > 1. The ftp-masters removed ia32-libs-tools with the following message > from the archive "RoThe Project; Most idiotic breakage ever.". About > 45 mintes later (and not linked) they sent out this mail to > debian-devel http://lists.debian.org/debian-devel/2009/07/msg00060.html > > 2. The tech ctte was asked by Goswin to overrule the ftp-maintainer > decision to remove ia32-libs-tools. > > 3. After careful review, the transition plan to multiarch from Goswin > that includes usage of this tool doesn't seem to have broad support. a) It is not a transition plan to multiarch but rather a plan away from ia32-libs-tools once multiarch becomes a reality. b) It doesn't really include the use of the tool but is for people that already do use the tool and should then use multiarch. c) The changes are internal to ia32-libs-tools. I'm not asking maintainer to change their packages. Do you have broad support for every change you do in netpbm, mgetty or pppoe? d) Is Steve plain against ia32-libs-tools (which is my impression) or does he see fault in the plan for how to get rid of ia32-libs-tools smoothly? Are any core maintainers against the plan for which they have to do nothing? If ia32-libs-tools stays removed what is his plan to deal with the existing ia32-* packages? > 4. However, the implementation plan for multiarch from Steve has broad > support, with buy-in of key maintainers. And is a completly different subject. The multiarch plan is a release goal with or without ia32-libs-tools and unlike ia32-libs-tools multiarch requires that maintainers actually do something. > 5. Steve is driving that implementation plan for some time, and he > explicitly disagrees (with stated reasons) with the presence of > ia32-libs-tools in the archive. The way I see it all he said is true now. There are many users with ia32-* packages from various ia32-libs-tools versions installed and when multiarch comes they will now cause override errors in dpkg, cause missing symbols and segfaults in random programms and will confuse people. Since the ia32-abi provide was only added in the last version many people will not have upgraded to that one and there will be no simple way to conflict. By keeping ia32-libs-tools on the other hand users will have ample time to upgrade the generated packages to versions that will not cuase these problems. In a way he makes a point for ia32-libs-tools even if he doesn't see it that way. After 1 1/2 years of use it is a bit too late, to put it blantly, to stick ones head in the sand and sing "La, la, la. ia32-libs-tools doesn't exists". > 6. The way the decision of removal was communicated to Goswin seems > suboptimal to me. This however doesn't make the decision wrong. > > 7. Considering all these facts, I would recommend the tech ctte > to refuse to overrule the ftp-masters. > > > > Comments? > > > > Cheers, > Andi MfG Goswin -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
