Re: Bug#535645: Bug #535645: Wrongfull removal of ia32-libs-tools
Steve Langasek <vorlon@debian.org> writes:
> On Thu, Aug 20, 2009 at 02:31:35PM +0200, Goswin von Brederlow wrote:
>> > My understanding is that the CTTE was asked first to clarify the
>> > reasoning surrounding the removal of ia32-libs-tools et al.; and only
>> > take up discussions with regards to overriding the decision
>> > afterwards.
>
>> > Goswin: have the reasons for removal been clarified to your
>> > satisfaction, or do you still want the CTTE to consider overriding the
>> > ftpmasters? [If the latter, I'd suggest summarizing the discussion to
>> > date as succinctly as possible, with the issues that lead to the
>> > removal and your position on the severity and/or possible mitigation
>> > and elmination of those issues. Otherwise, one of us will have to, and
>> > that'll take longer.]
>
>> So far I have not seen a real clarification from Joerg, only from
>> Steve Langasek as head of the multiarch proposal. But I guess we can
>> take his silence as that the reasons Steve gave are the only ones.
>
> An unfounded conclusion. The ftp team have not been subscribed to this bug
> or cc:ed on this mailing list thread.
Wrong. Andreas Barth specifically asked ftp-master for clarification
in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535645#58
There has been no responce to that request that I can see.
> If the primary object of this bug report is to get a clarification from the
> ftp masters, then this is quite irregular. Since the constitution states
> that "Nothing in this constitution imposes an obligation on anyone to do
> work for the Project", we have no authority to compel the ftp masters to
> explain their removal decision in any more detail than they already have;
> constitutionally, the only authority the TC has is to override the removal
> decision.
Sorry, but that argument is just bullshit. By voluntary accepting the
job of ftp-master the persons have accepted a moral obligation to do a
good job, to be open and accountable.
As you say the TC has the authority to override the removal
decision. And the first step to deciding wether or not the decision
should be overridden must be finding out the reasons for the
decision. The TC might not have a constitutional authority to demand
an explaination but I sure would hope it would override any decision
for which ftp-master, or any delegate for that matter, is unwilling or
unable to give a reason for. Having a small subset of Debian making
secret decisions for all of Debian goes against everything Debian
stands for.
You might not have the authority to demand an explaination but you do
have to power to make them give one or be overruled. What I'm asking
for is your willingness to weald that power.
> I've cc:ed the ftp team now and invite them to make clear their objections
> to reintroducing the ia32-apt-get package in the archive, since so far we
> have only inference and speculation to go by. I do think it's important
> that when the ftp team makes decisions about package inclusion in the
> archive, that there be empirical, measurable reasons supporting those
> decisions; and that, at least upon request of a DD, the ftp team be willing
> to spell out the conditions for a package's acceptance into the archive
> (which may be a superset of the reasons for refusal).
>
> Note that I say DD, since non-DD maintainers aren't in a position to upload
> new packages directly to the archive anyway; the ftp team shouldn't feel
> compelled to justify package rejects / removals if no one with upload rights
> is contesting the decision.
That request has been made by Andreas Barth.
>> With that information I would claim that the ia32-libs-tools issue is
>> a disagreement between a DD and a maintainer and that falls under the
>> scope of the Debian CTTE and not ftp-master. So ftp-master had no
>> right to take sides and just remove the package even if they have the
>> power to do so.
>
> False. The ftp team did not remove the package from the archive at my
> direction, and even if they had, the authority to make that decision is
> theirs, not mine. You don't get to game the tech committee's rules just
> because a member of the TC argues against your position.
>
> In this thread, I have merely elucidated the reasons why I don't believe the
> ftp-master decision should be overridden and why I would be unlikely to make
> a different decision in their place.
Ok, so we are still 100% in the dark why ia32-libs-tools was removed
from the archive. In my eyes that makes the removal arbitrary.
>> I further pointed out the similarity to dpkg-cross, which has been in
>> Debian since 1997. The difference between ia32-libs-tools and
>> dpkg-cross are implementation details. They basically do the same and
>> if I wouldn't hate perl so much then I would have patched dpkg-cross
>> instead of writing ia32-libs-tools. So there is a 12 year precedence
>> for ia32-libs-tools like tools. There is a long history of doing what
>> ia32-libs-tools does, altering debs between download and installation,
>> even if for a slightly different goal.
>
> I don't think any of this is a justification for overriding the ftp team.
> The ftp team is not obligated to treat any package as binding precedent when
> considering the acceptance or removal of another.
>
> Concretely, as I have argued previously, there is a difference of scale
> between ia32-apt-get and other related tools. dpkg-cross is ugly, but it is
> low level and therefore has built-in barriers to adoption; it's not a tool
> that casual users are going to use to cross-install arbitrary libraries,
> it's a tool that embedded developers can use as a basis for their own
> private infrastructure to set up and maintain cross-build environments.
>
> It also, last I looked at it, was entirely free of the potential multiarch
> file conflicts discussed in this bug. (I acknowledge that you have agreed
> to address these issues for ia32-apt-get, but at the time the package was
> removed it's my understanding that they had not been addressed.)
True. But I have never been asked to address them. Implementing
compatibility with multiarch requires multiarch to be implemented at
least party. You can not expect ia32-libs-tools to be compatible with
multiarch before it even was specified what it is.
>> So in conclusion I would ask the CTTE to suspend the ftp-master
>> removal and then mediate between Steve and me.
>
> As I have not made any decision in this matter aside from my decision how to
> vote on the question of overriding the ftp-masters, you don't have standing
> to make this request.
As said above. We are then back to 100% having no clue why ftp-master
removed the package.
>> On the other hand I have, based on the multiarch proposal from Steve,
>> detailed briefly [1] how ia32-apt-get will adapt to and actively use
>> multiarch features as they are being added to Debian. With those steps
>> ia32-apt-get users will transition smoothly to multiarch. And for
>> those users that stop using ia32-apt-get I proposed that the multiarch
>> capable dpkg will "Conflicts: ia32-abi", thereby causing the removal
>> of any ia32-* package left installed when multiarch comes.
>
> If the multiarch-capable dpkg Conflicts: ia32-abi, this has the effect of
> forcing removal of all ia32-apt-get-installed packages before the new dpkg
> is unpacked. This all but ensures that the upgrade path for any users of
> these 32-bit packages to multiarch will involve full removal of the packages
> (including any application packages) followed by a manual reinstall after
> apt has been upgraded.
Not quite right. This will only happen for people that stop using
ia32-apt-get or when a transition turns out to be impossible.
On the other hand if you use ia32-apt-get the packages metadata are
changed on the fly. Depends, Conflicts, Breaks, Provides, ... are
changed where needed. If the ia32-apt-get -> multiarch process works
out as planed then the "Conflicts: ia32-abi" of dpkg will just be
removed on the fly. The effect will be this:
apt-get install dpkg ---> remove all ia32-* packages
or
ia32-apt-get install dpkg ---> installs cleanly
ia32-apt-get install ia32-apt-get
ia32-apt-get update
ia32-apt-get dist-upgrade ---> replaces ia32-* packages with multiarch
The conflicts is a safety net for users that use ia32-apt-get now but
stop using it before multiarch replaces it.
> I don't think that's the kind of user experience we want to present our
> users on upgrade, and yes, I would rather they not install these 32-bit
> packages in the first place than have them have to reinstall them manually
> after upgrade. But I don't think the Conflicts: ia32-abi is actually
Note that you have the same with ia32-libs, ia32-libs-gtk,
ia32-libs-xulurunner, ... The experience doesn't really change.
Quite the reverse. If my plan works out people will not have to
reinstall anything but just upgrade.
> anything that's needed to address *my* concerns with ia32-apt-get; I think
> it's a spurious invention predicated on the position that we must not have
> two versions of a library co-installed in the multiarch and biarch paths,
> which I've previously indicated is a position I don't agree with. I believe
> my actual concern is adequately addressed by just ensuring ia32-apt-get
> packages never install to the multiarch paths.
That is fine by me.
> But I didn't bother raising this objection earlier because frankly, I resent
> this issue taking the time of the TC. ia32-libs and ia32-apt-get are widely
> acknowledged to be ugly kludges, and the time I've spent responding to this
> thread is time that would have been better spent working on multiarch.
Also widely though of as usefull and a better solution than ia32-libs.
For example Len Sorensen wrote:
http://lists.debian.org/debian-amd64/2009/08/msg00030.html
| It seems weird, but yes it has disappeared again. It seemed like
| such a neat idea and much more flexible than the ia32-libs
| packages. I wonder what the next multiarch method will be.
Yes, ia32-libs-tools is controversial. But I still believe it is the
better of two evils. It just makes less problems for users than
ia32-libs and ia32-libs-gtk.
> That, above all, is why I have no intention of voting other than to uphold
> the ftp-master decision. While I'm not aware of any technical concerns of
> mine that have not been addressed in this thread, I don't think it's worth
> my effort to assure myself that they're addressed to the point that I'm
> willing to override the ftp masters - first, because some of the technical
> concerns which have been addressed were not new concerns, and apparently
> were only addressed once you believed yourself at the mercy of the TC for
> getting the package into the archive, so I'm not confident that new problems
> won't emerge once the package is back in the archive; and second, because
> ia32-* is a stopgap.
What do you refer to? Where did anyone ask me to address a concern
other than here and I didn't reply?
> I would have no objections to the ftp team allowing ia32-apt-get back into
> the archive, but I'm going to vote against overriding them; and barring a
> motion from another TC member to override the ftp team, I don't intend to
> spend more energy on this thread. If you want to see this package back in
> the archive, I recommend that you persuade the ftp team that /their/
> concerns with the package are addressed.
Ftp-master did not ask me to change ia32-libs-tools, they just removed
it.
Ftp-master does not tell why they removed it. They only say they won't
let it back.
And now I am supposed to magically address the concerns nobody is
willing to state?
Do you see the problem?
MfG
Goswin
Reply to: