Re: request for Technical Committee ruling on Bug #109436
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
> 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: