request for Technical Committee ruling on Bug #109436
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
branden@deadbeast.net | assimilated by the Borg.
http://www.deadbeast.net/~branden/ |
Date: Wed, 22 Aug 2001 14:42:26 -0500
From: Branden Robinson <branden@debian.org>
To: control@bugs.debian.org, ctte@debian.org
Cc: 109436@bugs.debian.org
Subject: request for Technical Committee ruling
In-Reply-To: <handler.109436.D109436.99840311824070.notifdone@bugs.debian.org>
User-Agent: Mutt/1.3.20i
reopen 109436
tags 109436 wontfix
forwarded 109436 ctte@debian.org
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
<109436@bugs.debian.org> 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
branden@debian.org | Dad...not screaming in terror like
http://people.debian.org/~branden/ | his passengers.
Reply to: