Does the technical committee really need to get involved here? It sounds like all you have to do is give the source package a new name. On the non-technical side, maybe should declare a that the upstream sources have been forked, and that you're maintaining a package which is based on those forked sources.
However, on the technical side, all I can see is a tar file name issue. Let us know if I've got this wrong. Thanks, -- Raul On Wed, Aug 22, 2001 at 02:57:55PM -0500, Branden Robinson wrote: > 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.
