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