Re: request for Technical Committee ruling on Bug #109436
On Thu, Aug 23, 2001 at 04:59:36PM -0400, Raul Miller wrote:
> I understand that. However, consider also 6.3(6).
The archive maintainers and I are deadlocked. I cannot think of a
solution that involves neither them yielding nor me.
> And, for that matter, the part of 6.3(5) that ends "reasonably
> thoroughly discussed elsewhere".
Is it your opinion that the logs of bug 109436 do not qualify as a
reasonably thorough discussion of the issue?
> Also, consider that if we do take this on, we'll probably make our
> decision on technical grounds, and so far you've not given any for
> your proposal.
You appear to be construing "technical grounds" as anything the archive
maintainers have to do, and nothing the package maintainer has to do.
Please provide me with a definition of "technical grounds" that is
operative for you.
> Instead, you've mostly been focusing on issues of precedent. Precedent,
> to us, mostly matters in the context of questions like "what breaks?",
> "what does this enable?", and "what do the specs say?"
"What breaks?" The archive, if its administrators neither have code to
accomodate the situation in question, nor handle it manually.
"What does this enable?" If .orig.tar.gz changes after dinstall are
always forbidden, nothing. It relieves the archive maintainers of ever
having to handle situations like mine. If .orig.tar.gz changes after
dinstall are permitted, it enables package maintainers to make changes
to the .orig.tar.gz when necessary, in ways that don't disrupt the
continuity of the package's naming or versioning.
I can already hear your objection, so let me ask you if you would
consider a hypothetical situation where the "glibc" source package
changed its name and versioning scheme (requiring an epoch in the Debian
version) with every upload. Is that scenario a "technical" one?
> > If I'd been aware of xc/util/patch's licensing before I released
> > 4.1.0-1, I would not have included it. The same goes for every previous
> > release of XFree86 I have made.
>
> None of us know everything.
Should I take this to mean that the Technical Committee does not feel
that the requisite change to the XFree86 source tarball did not happen
because I am maintaining the package in a substandard or irresponsible
manner?
> You are correct. They're giving you more latitude than I would have
> been.
This does not sound like an objective remark from someone who is
supposed to be acting in a neutral capacity.
> > Such a Policy is neither present, implicit, nor precedented, since in
> > the past it was perfectly possible to change an .orig.tar.gz by simply
> > uploading a new one and referencing it accurately in a .dsc file.
>
> D.2.12 defines the part of the old .dsc file which you're breaking.
I cannot agree with this reading of D.2.12 (which we should both note
-- since it is part of the appendix to the Debian Policy Manual -- is
not binding on developers since it hasn't been brought up to date; but,
for the sake of argument, I'll pretend that it is).
It says "In the .dsc (Debian source control) file each line contains the
MD5 checksum, size and filename of the tarfile and (if applicable) diff
file which make up the remainder of the source package."
We can probably agree that neither the old nor the new .dsc files are,
or need be, syntactically invalid to accomodate the end I am seeking.
It further says "If a new Debian revision of a package is being shipped
and no new original source archive is being distributed the .dsc must
still contain the Files field entry for the original source archive
package-upstream-version.orig.tar.gz, but the .changes file should leave
it out. In this case the original source archive on the distribution
site must match exactly, byte-for-byte, the original source archive
which was used to generate the .dsc file and diff which are being
uploaded."
What I am doing is shipping a new Debian revision of a package *and*
distributing a new original source archive. Therefore it is not
required that the original source archive on the distribution site match
exactly, byte-for-byte, the original source archive which was used to
generate the .dsc file and diff which are being uploaded.
> This should probably be enhanced so that it says something along the
> lines of "If a file name has appeared in a previous .dsc file, the file's
> md5sum must match that previously given".
This is the same thing as saying that changes to the .orig.tar.gz are
not allowed without a change in the upstream version number.
> Do you see any flaws with the sentence I just now proposed?
Yes, I think it places gratuitous restrictions on the package
maintainer.
> If the ftp admins have gotten around to implementing any kind of integrity
> checks in place (where files with improper md5sums are not propagated),
> the way to do what you ask could involve manually deleting every copy of
> xfree86 4.1.0 off of every official mirror before uploading your new copy.
> And this might still hose unofficial mirrors.
I do not see how this is any different from mundane cases of archive
corruption. As long as the katie database, which contains the proper
md5sums for each file, is updated to reflect the change in the canonical
file, I see no *technical* reason why changes to existing files are
impermissible.
And, if you'll recall my original mail, I was not asking for the
new .orig.tar.gz to be dropped into the archive with no other action
taken.
> Is that what you want? This might take several weeks, or longer.
What about cases where we have to yank an .orig for legal reasons? Does
it take several weeks to propagate the file removal? Is the mirrors'
exposure to liability our problem or theirs?
I see no archive management problems imposed by the scenario at issue
that aren't imposed by other scenarios which we can't legislate away
with Policy.
Furthermore, I'll note that, in this case, because no code in the source
tarball in question is GPL'ed or LGPL'ed, there are no issues with "must
make available source code corresponding the binary" or even
requirements to provide the source at all. So there are no license
violation issues with there existing a window of time in which a source
tarball is "incorrect" or unavailable. Moreover, since the only change
was to code that was completely unused, the "wrong" old tarball is still
*usable* to build binary packages, though I wouldn't encourage anyone to
do so.
--
G. Branden Robinson | The software said it required
Debian GNU/Linux | Windows 3.1 or better, so I
branden@deadbeast.net | installed Linux.
http://www.deadbeast.net/~branden/ |
Reply to: