Re: request for Technical Committee ruling on Bug #109436
On Thu, Aug 23, 2001 at 09:11:01AM -0400, Raul Miller wrote: [I'm not calling for a vote yet, we're still in discussion on this, and I'm still not sure that this situation requires our participation at all.] It looks to me like the right thing to do here is: [1] Do something so the new tar.gz file has a file name distinct from the old one. [Guy Maor suggested incrementing the epoch.] I'm told by folks familiar with katie that using an epoch won't work, because epochs do not appear on .orig.tar.gz filenames. The upstream tarball would thus remain un-renamed from the perspective of the katie database. Any better ideas? Why is the right thing to do not to consider asking the archive maintainers to grant my request? -- G. Branden Robinson| What influenced me to atheism was Debian GNU/Linux | reading the Bible cover to cover. [EMAIL PROTECTED] | Twice. http://www.deadbeast.net/~branden/ | -- J. Michael Straczynski
Re: request for Technical Committee ruling on Bug #109436
Raul == Raul Miller [EMAIL PROTECTED] writes: Raul It looks to me like the right thing to do here is: Raul [1] Do something so the new tar.gz file has a file name distinct from Raul the old one. [Guy Maor suggested incrementing the epoch.] This should work(well, not the epoch, but a rename of the source) , but I am not convinced this is the correct thing to do. Raul [2] File a bug report against ftp.debian.org to get the old Raul tar.gz file pulled. In this case, I would prefer this (because of the DFSG violations). In general, though, this could cause problems with licence violations until the other archs caught up (we would be distributing binaries without the corresponding source) Raul [3] File a bug report against policy so steps [1] and [2] are clearly Raul documented. Raul Currently policy on Epoch says: Raul It is provided to allow mistakes in the version numbers of Raul older versions of a package, and also a package's previous Raul version numbering schemes, to be left behind. Raul This is a bit too narrow as it doesn't talk about the need for Raul distinct instances of the same version of the upstream tarball. The epoch is not the solution here, so this is moot. epochs are for version number screwups, and do not affect the original sources. manoj -- Card readers? We don't need no stinking card readers. Peter da Silva (at the National Academy of Sciences, 1965, in a particularly vivid fantasy) Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: request for Technical Committee ruling on Bug #109436
On Thu, Aug 23, 2001 at 11:28:12AM -0500, Branden Robinson wrote: I would suggest that what the katie software currently does is the right thing in the majority of cases. But once in a while, circumstances will arise that require replacement of an .orig.tar.gz without a rename. I am asking for official recognition of that fact as a general principle, and in this specific case I am asking for the scenario at issue in #109436 to be regarded as such an exceptional case, because it is Debian policy that is compelling me to change the upstream sources. Ok, you seem to be asserting that the right thing, in this context, is to distribute the new tarball as if it were the old one. Sure, you can tell a human look for the file with this number of bytes, but a lot of this stuff is automated. I don't think the archive maintainers would assert (though it may be wise to ask them) in this case that the .orig.tar.gz that needs to be replaced, and the replacement, are difficult to distinguish. One is already in the pool, the other is in incoming. The new one is also referenced by the 4.1.0-3 .dsc file in incoming. Needless to say, I am willing to furnish them with whatever additional information they may need to fulfill my request. As you almost imply, the .dsc files for prior versions of the package will give improper md5sums for the new tarball. This strikes me as a problem, unless we're going to rely on us ignoring those md5sums. Are you willing to re-upload each of the prior debian releases, with fixed .dsc files, which have the md5sum of the new tarball? Or, if not all prior releases, at least those releases which are in the package pool? [I'm not saying this is the right solution -- I'm asking to you to look at what you're asking.] Also: please tell me what's wrong with releasing a 4.1.0.,dfsg version. Thanks, -- Raul
Re: request for Technical Committee ruling on Bug #109436
Also: please tell me what's wrong with releasing a 4.1.0.,dfsg version. Actually comma is an illegal character -- but the following alternatives look valid: 4.1.0. 4.1.0+ 4.1.0+dfsg On Thu, Aug 23, 2001 at 12:52:55PM -0500, Branden Robinson wrote: Simply put, I don't want to do it. You do understand that this isn't a technical issue? Now, if you're concerned about inventing a name which will have ordering problems when xfree86 releases their next version, that would be a technical issue. There may be other technical issues here, as well. It's my package, and I like the name and upstream version number as they are -- clear and unambiguous. I'd think it's pretty clear that 4.1.0. is the same version as 4.1.0 I have not forked the upstream sources, and I have no intention of doing. The upstream authors are aware of my changes to their source package (we have agreed to disagree on the font licensing issue which led to the removal of some Type1 fonts from the source package -- see the xfonts-scalable-nonfree source and binary packages). Furthermore, I do not see my XFree86 packages as being substantially divergent from upstream sources. My changes are documented in the copyright file. If you were to ask the XFree86 Project, Inc., if what I am packaging for Debian can legimately be called XFree86, I am confident they would say yes (they are quite tolerant of non-disruptive [i.e., don't break library ABI's] customizations that distributors need to make). If it would help you to make an informed decision in this matter, however, I would urge you to ask them at [EMAIL PROTECTED] (that is the address for their Board of Directories, so as to faciliate an authoritative reply). Ok, so don't say that you've forked it, because you haven't. Furthermore, I do not recognize the authority of the archive administrators to tell me what I may or may not name my package, as long as it complies with policy (2.3.1) and doesn't collide with the name of a package I don't maintain. We're talking about a new version of the source tarball. You're saying that the new version isn't very different from the old one, and that the old one should never have existed. On the other hand, the old one does exist. The admin folks are saying: if you don't want the old version, use a new version. Similarly, Chapter 4 of the Debian Policy Manual is quite clear to what is acceptable in a package version number. My package's name and version number are compliant with policy, and beyond that I feel package maintainers should be left free to exercise their discretion when it comes to stylistic details. See clause 3.1.1 of the Constitution (An individual Developer may make any technical or nontechnical decision with regard to their own work). Um.. but putting your package out on the archives is the work of the admin folks, isn't it? If the archive maintainers want to impose further restrictions, I think they should have to submit a proposed amendment to the debian-policy list. We need explicit policy that says any change to the source tarball requires a new version number? Alternatively, the Technical Committee can exercise its authority to update the Policy Manual accordingly. If the Technical Committee decrees that it shall be Debian Policy that package maintainers shall name and version their packages as the archive maintainers dictate, then I guess that's how it will be. I'm not ready to make a proposal that we do such a thing. I want to understand what technical reasons you have for your proposal. I don't want to change the version number, while literally accurate, doesn't help me understand why you think we should use same file name for corrected and uncorrected source tarball. Call me stupid if you want, but please spell this out. Thanks, -- Raul
Re: request for Technical Committee ruling on Bug #109436
On Thu, Aug 23, 2001 at 03:25:09PM -0400, Raul Miller wrote: You do understand that this isn't a technical issue? On Thu, Aug 23, 2001 at 02:58:25PM -0500, Branden Robinson wrote: It is, however, an issue upon which the Technical Committee is empowered to rule: I understand that. However, consider also 6.3(6). And, for that matter, the part of 6.3(5) that ends reasonably thoroughly discussed elsewhere. 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. 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? We're talking about a new version of the source tarball. Correct, if you are referring to file contents. Yes. You're saying that the new version isn't very different from the old one, and that the old one should never have existed. 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. On the other hand, the old one does exist. The admin folks are saying: if you don't want the old version, use a new version. I hesitate to speak for the archive maintainers, but I don't think they're saying exactly that. They're saying if you want a new version, rename the file. You are correct. They're giving you more latitude than I would have been. We need explicit policy that says any change to the source tarball requires a new version number? 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. 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. So, yes. If that's how the Technical Committee rules, that's what we need. I would argue that the new policy should not be categorical about it. Do you see any flaws with the sentence I just now proposed? I do not think Policy should compel me to both change my .orig.tar.gz ASAP and at the same time compel me to perpetrate some kludge upon its name and/or version, when such a change is not otherwise pending. To further elaborate, I would be satisfied with a Policy that said maintainers are not allowed to change an .orig.tar.gz that exists in the archive *unless* they're compelled to do so by some other aspect of Debian Policy. I think it quite reasonable for the archive maintainers to not want developers to go changing .orig.tar.gz's on a whim (because it can cause problems, as they have pointed out). I do not think it is reasonable for the archive maintainers to have an urwritten policy that effectively attributes all changes to .orig.tar.gz's to developer whims, meriting rejection of the change. 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. Is that what you want? This might take several weeks, or longer. [Even if we don't have this implemented now, it's quite reasonable that we'd have something like this implemented in the near future.] -- Raul
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
Re: request for Technical Committee ruling on Bug #109436
On Thu, Aug 23, 2001 at 04:59:36PM -0400, Raul Miller wrote: I hesitate to speak for the archive maintainers, but I don't think they're saying exactly that. They're saying if you want a new version, rename the file. You are correct. They're giving you more latitude than I would have been. One question I forgot to ask: Can you clarify to me exactly what latitude I'm being given by the archive maintainers? -- G. Branden Robinson| Debian GNU/Linux | It tastes good. [EMAIL PROTECTED] | -- Bill Clinton http://www.deadbeast.net/~branden/ |
Bug#109436: request for Technical Committee ruling on Bug #109436
On Wed, 22 Aug 2001 15:26:29 -0500, Branden Robinson wrote: [...] Where I differ with the archive maintainers is that they are telling me that I don't have a good reason to deviate from that practice in this situation, and I think I do. Debian Policy is compelling me to change the upstream source tarball. When policy compells you to change foo_1.0-1_i386.deb, you upload foo_1.0-2_i386.deb. In this case, policy is compelling you to change foo_1.0.orig.tar.gz, and you should correspondingly expect to change the version number. There's no problem with changing the upstream tarball, but there is a problem with trying to call it by the same name as the old version. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net)
Re: request for Technical Committee ruling on Bug #109436
On Thu, Aug 23, 2001 at 10:43:31AM -0500, Manoj Srivastava wrote: Guy == Guy Maor [EMAIL PROTECTED] writes: Guy I agree with the archive maintainers. No deb or diff.gz is allowed to Guy change without a filename change. Why should the orig.tar.gz be Guy different? A mirroring scheme could depend on this behavior. Because we control the deb and the diff, but we do not control the pristine upstream sources, which may have well known cryptographic signatures on them outside the scope of Debian to affect. If we didn't control the pristine upstream source this wouldn't be an issue, as Branden wouldn't have been able to remove the non-DFSG-free components from the tarball. But he was able to, and thus does have control over the upstream source (which isn't pristine per se anyway). Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net)
