Sorry, I was unaware that the Technical Committee had a virtual package in the BTS and a mailing list of its own.
-- G. Branden Robinson | Debian GNU/Linux | "Bother," said Pooh, as he was [EMAIL PROTECTED] | assimilated by the Borg. http://www.deadbeast.net/~branden/ | Date: Wed, 22 Aug 2001 14:42:26 -0500 From: Branden Robinson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: request for Technical Committee ruling In-Reply-To: <[EMAIL PROTECTED]> User-Agent: Mutt/1.3.20i reopen 109436 tags 109436 wontfix forwarded 109436 [EMAIL PROTECTED] thanks Because the "package maintainer" (in this case the Debian archive administrators collectively) and I cannot agree on the resolution of this bug, I am appealing to the Technical Committee under sections 6.1.1, 6.1.2, and 6.1.3 of the Constitution. 6.1.1 holds that the Technical Committee is empowered to decide on matters of technical policy; 6.1.2 holds that the Technical Committee is empowered to decide on technical matters where developers' jurisdictions overlap; 6.1.3 holds that the Technical Committee is empowered to decide on issues when they are asked to do by a developer. The scenario is this: I was recently informed (on August 6th) that the .orig.tar.gz file for the xfree86 package contains code in it that fails the DFSG, which is a "serious" violation of Debian Policy (that is, section 2.1.2 of the Debian Policy manual says that my package *must* comply with the DFSG). My response to this problem report was to excise the non-DFSG-compliant code from the source tarball and re-generate the .orig.tar.gz file. This is all that was necessary because the code in question was dead, and unused by the package during its build or execution (in fact, upstream, XFree86 has removed this code from their CVS tree since it is unused and fails to meet their licensing requirements). I proceeded to include this change with my next package revision, as any other bugfix (albeit one that wasn't filed with the BTS), and used the "-sa" option to dpkg-buildpackage to create the package, which I proceeded to upload. The archive administrators have elected not to install this package because the .orig.tar.gz file has changed. It is my understanding that it is a requirement of the new "package-pools" based archive management system that a file so managed cannot ever change its size or md5sum without changing its name. Therefore, changing an upstream source archive -- one it has been dinstalled -- is effectively forbidden now (it did not used to be). My objection is that this is effectively an undocumented "must not"-style policy requirement, and that it should be documented in the Policy Manual because it is effectively unconditional. This makes a much stronger dictum even than most "must" directives currently in the Policy Manual. At one point, a person who was attempting to justify the archive maintainers' decision to me quoted Chapter 4 of the Policy Manual: upstream_version This is the main part of the version number. It is usually the version number of the original (`upstream') package from which the .deb file has been made, if this is applicable. Usually this will be in the same format as that specified by the upstream author(s); however, it may need to be reformatted to fit into the package management system's format and comparison scheme. He asserted that I can change ("reformat") the upstream version at any time. However, I would not be changing the upstream version to fit the requirements of the package system's format and comparison scheme, since the upstream version number "4.1.0" is perfectly comprehensible to the packaging system, and in the time I have been maintaining XFree86 I have not known them to release their software with a version number that breaks the assumptions made by our package manager. It is important to me that the version number in our Debian packages of XFree86 reflect the upstream version number as closely as possible. Clearly the "-debian_version" syntax is mandatory, but I do not see any formal reason why a change in the version number should be imposed upon me by the archive maintainers. To the best of my knowledge, it is not technically infeasible for them to accommodate my request for installation of the package; as I understand it, the following things need to happen: 1) The 4.1.0 .orig.tar.gz current in the pool needs to be replaced; 2) The record corresponding to this file in the SQL-based database in which package information is stored needs to be updated. (This database is sometimes called the "katie database" but I do not know if this is correct; James Troup is probably the person to ask). 3) Any .dsc files in the pool that reference the original .orig.tar.gz (which includes the non-DFSG code) either need to be modified or removed from the pool along with their corresponding .diff.gz's and .debs (and database entries, if and as necessary). Step 3) I do not regard as egregious collateral damage, since all architectures slated to release with woody need to build the new 4.1.0-3 version of XFree86 anyway (and even unreleasing architectures are interested in having working X libraries, so I am frequently in contact with them as well to apply patches and so forth). I am willing to do whatever is within my power to help expedite the process of getting the various architectures back up to date using the new source tarball (indeed, I can build 4.1.0-3 for three other architectures [not including i386, which is already uploaded] myself). I understand that a request of this nature to the archive maintainers is much more labor intensive than the typical dinstall run; however, scenarios like this, where an existing .orig.tar.gz *has* to be changed because of legal or Debian Policy, are in fact uncommon. My opinion is that it would be better for the archive maintainers to have procedures in place for handling these uncommon situations than it is to add a new super-mandatory clause to the Debian Policy Manual, but I am willing to respect the latter decision if that is what is made. I do request, however, that if the Technical Committee rules "in favor of" the archive maintainers on this issue, that the Debian Policy Manual be updated to reflect this de facto policy. Currently, the only way developers are to know a priori that they can't change their .orig.tar.gz's after one has been placed in the archive is through IRC and other such informal channels. It might also be a good idea to update the dpkg-source(1) manual page to mention this fact. However, I urge the Technical Committee to consider that requests such as mine are uncommon, that the archive maintainers need a set of internal procedures in place to handle them, and that they need to be willing to apply them when circumstances dictate. (I was told in conversation with the advocate mentioned earlier that there could be exceptions to the rule of "no changes to orig tarballs", but that he couldn't think of any. I would suggest that a rule without identifiable exceptions is indistinguishable from a rule without any exceptions.) I have attempted to be objective in this message, however I am certain there are nuances I am forgetting. Therefore I would ask the Technical Committee to read the bug log of #109436, and solicit further information from the archive maintainers, before rendering a final decision. Also, if there are points that I can help to clarify, please don't hesitate to mail me. I also think we should Cc <[EMAIL PROTECTED]> during this process so that there is a permanent record of it. -- G. Branden Robinson | When I die I want to go peacefully Debian GNU/Linux | in my sleep like my ol' Grand [EMAIL PROTECTED] | Dad...not screaming in terror like http://people.debian.org/~branden/ | his passengers.