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 [EMAIL PROTECTED] | installed Linux. http://www.deadbeast.net/~branden/ |
