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. That would mean that you won't be submitting any useful packages for X 4.1.0. > I cannot think of a solution that involves neither them yielding nor > me. I understand. > > And, for that matter, the part of 6.3(5) that ends "reasonably > > thoroughly discussed elsewhere". On Thu, Aug 23, 2001 at 04:29:51PM -0500, Branden Robinson wrote: > Is it your opinion that the logs of bug 109436 do not qualify as a > reasonably thorough discussion of the issue? Looking at it from a technical point of view (in terms of software design issues), no -- I don't think it's reasonably thorough. Nor does it look like there was much of an effort to achieve a consensus. > > 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. I don't construe it that way. Things the package maintainer has to do are technical grounds. So far, I don't see that the amount of work the package maintainer would have to do is anywhere near comparable to the amount of work the archive maintainers would have to do. > Please provide me with a definition of "technical grounds" that is > operative for you. Technical grounds, in this context, refers to software design issues. My view on software design is that, includes: Interfaces are Sacred (they may seem trivial, but when you break them you start finding all sorts of people who are affected by the change but who weren't part of the discussion before the interface was broken). Or: before you change a documented interface, you should get everyone involved into the discussion. Single point of control is generally a good thing in software, except where you explicitly don't want something to change (see above: Interface are Sacred, this is also somewhat relevant with security but that's another discussion), or where it destroys the abstractions you consider important. Is that enough for you, or do I need to elaborate further? > > 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. Agreed. I don't think breaking the archive is a good thing. Do you? > "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. Note that we're talking about source package here changing the source package doesn't require changing the binary package names. However, this goal -- allowing source file contents to change without changing the name -- seems, to me, to have the following results: [1] confusion. When random user reports issue with source file such and such, I don't know which file they're talking about. [2] integrity violation. Changing source file contents without changing names means that there are some valid situations where an official md5sum doesn't match the official file. [3] extra chatter. Not only this discussion, but future discussions brought on by the above issues. I don't think these are good things. Do you? > 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? It's a hypothetical one. It's not one for this committee unless other developers have problems with it. [Otherwise: the package maintainer has complete discretion over this issue.] If this hypothetical situation did wind up in my face, I'd probably be advocating that the glibc maintainer used a systematic scheme [probably a suffix] to deal with whatever it was that he felt he needed to deal with. > > > 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? No, you should not take it to mean that. > > 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. "I would have" refers to the stuff I'd written which you had just responded to. You didn't quote that text here, but it's what I was talking about. > > > 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). Are you pretending that policy is the only relevant specification for this context? > 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's the validity of the md5 checksum for the filename that I'm obviously talking about. > 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." Yep. > 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. True: people do this all the time. But why did it take you several detailed paragraphs to leave out the bit about you not wanting to change the file name when the bytes don't match? That's the issue we're discussing and you went and wrote all these paragraphs and didn't even mention it. You're smarter than that. > > 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. As I believe you pointed out, the source package name can change without changing 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. Do you see any flaws other than that? > > 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. Archive corruption is localized: it doesn't suddenly invalidate every previously valid copy on several dozen mirrors. Furthermore, with archive corruption, you can take any machine where the md5sum matches the file contents and use that to fix the broken archive. If we look at your proposal from this point of view: the archive corruption is localized at incoming on ftp-master, and that copy should be ignored in favor of the copies already installed in the archives. > 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. You said, among other things: "The 4.1.0 .orig.tar.gz current in the pool needs to be replaced;" But this doesn't show any understanding of what really needs to happen to achieve that replacement. Maintaining integrity in distributed data sets is a bear unless you follow strict procedures during updates. Waving your hands isn't going to make that problem go away. You seem to be unwilling to discuss those problems. > > 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? Obviously it depends on the urgency. However, it's usually sufficient that you're taking reasonable steps to rectify the situation. > 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. The worst case scenario is that we have to purge a package as fast as possible, to hell with what breaks. No, actually: worst case scenario is that we shut down all debian mirrors until we resolve out some looming danger. Are you saying we should treat this situation as an instance of that scenario? > 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. Yep: this is a non-problem that you're talking about here. Which pretty much sums up most of this thread. FYI, -- Raul
