Re: Bug#535645: Wrongfull removal of ia32-libs-tools
Andreas Barth <aba@not.so.argh.org> 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
Reply to: