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. 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. 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. > 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. > 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.) > 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. > 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. 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 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. 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. 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. 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. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature