Re: request for Technical Committee ruling on Bug #109436
On Fri, Aug 24, 2001 at 09:54:13PM -0400, Raul Miller wrote: Branden solution: tarballname,md5sum relationship varies based on maintainers preference. [...] Branden solution: tarballname,md5sum varies if Debian Policy forces the maintainer to change it after it's been established. Ok. You don't see a distinction here? Are you willing to accept Wichert's statement about the implications of your solution? I had to go look his message up since he didn't deign to mail me, and the list archives are very slow. The catastrophe he describes won't happen if the new .orig.tar.gz is dropped into place along with 4.1.0-3 because: 1) X thus wouldn't disappear completely from the archive 2) all the X packages would continue to exist, so nothing would become uninstallable due to dependency problems To make things really seamless, we could wait until binary versions of 4.1.0-3 for every architecture currently at -1 or -2 have accumulated in incoming to do the transition. That wouldn't bother me. What does it mean if you have two different md5sums for the same file name? There's a reason files have timestamps. Say I install a package that uses dh_md5sums. One version may say that /usr/bin/foo has a given md5sum, the next version of the package says /usr/bin/foo has a different md5sum? What does it mean if you have two different md5sums for the same file name? It means the file changed. You've been relying on an undocumented practice for your interpretation. So have the archive admins for theirs. I think we can agree that it's not a documented interface. [...] I agree that more precise communication could have happened sooner. Unfortunately, we're limited to the present for what we do now. You be appear to be implying that whatever we do now is policy, when it's just as undocumented as what we did before; if that's the case, then what we did before the pool-ization of the archive was defacto policy. And under that policy, my upload was legal. Ad hockery bad. Documentation good. What does it mean to have two official md5sums for the same file? There aren't two official md5sums *simultaneously*. That's why the .dsc file changes, and why you update the katie database, natch. [Your psuedo code doesn't address this issue.] It wasn't intended to. It was intended to demonstrate the confusion that results when you add error checks behind the scenes, and don't warn people about them in the interface documentation beforehand. Python, for instance, uses a __future__ module to let people try out specification changes. Java specifications warn of deprecation a version or more before these deprecated interfaces become illegal. In this case, the archive maintainers changed (or implemented ) an undocumented rule without notice or warning. I understand that the general consensus appears to be Sucks to be you. Deal with it.; however, I question the wisdom of arranging things within Debian such that the archive maintainers always get to say this to package maintainers, and never have to hear it. The Policy Manual is mainly a document that governs the actions of package maintainers, less so one that governs the actions of the archive maintainers. I was told I had non-DFSG code in my source package. I checked it out. Yup. Damn. Sucks to be me. Deal with it. So I fix the problem in a way that used to work fine. Oh whoops, it doesn't now. Sucks to be me. Deal with it. I wonder how steady a diet of shit I get to eat before other people accept some culpability for this brain damaged situation. I could have R'ed the F'ing M...oh wait, there wasn't one. Unless I'm willing to put on Raul Miller's glasses and read D.2.12 in the right light while casting runes. Anyway, to get back to the point at hand, how often do we have to deal with DFSG violations in main? I read debian-devel-changes. It's pretty uncommon. Why is it so abhorrent to regard this as an unusual situation which requires unusual actions from *both* the package and archive maintainers? Not many users would confuse an orig.tar.gz with a deb Fortunately for you, you don't appear to be very familiar with some of my users. Count your blessings. What do you think about: xfree86-clean? clean could mean any number of things. I don't like it either. If I could think of one that I didn't think would promote confusion I'd have yielded on this issue already. I can't. So I'm going to ask whoever ends up making this decision (Jason Gunthorpe says the Technical Committee isn't even empowered to rule here, so I guess you guys still need to decide whether you have jurisdiction) to accept the responsibility that comes with power, and dictate one to me. Don't want that responsibility? Damn. Sucks to be you. Deal with it. [Not a lot of fun, is it?] It doesn't, but it does imply that there's an issue here, since it talks about the unique identity of a file. As you said yourself, the implication affords at least few
Re: request for Technical Committee ruling on Bug #109436
On Mon, Aug 27, 2001 at 10:42:16AM -0400, Dale Scheetz wrote: Branden, can you explain why this isn't a satisfactory solution for you? Raul has contacted Larry Wall and we're going to be able to put a band-aid on the offending code. It can be removed next time a new upstream release is made. In short, the need to change my .orig.tar.gz has been lifted. What I object to is the combination of the following: 1) Package maintainers being forced to modify .orig.tar.gz's by Policy; 2) Package maintainers being forced to rename .orig.tar.gz's when they are modified; If only one of the above restrictions (it doesn't matter to me which one, but for practical reasons we need the first rule more because of the imposition of circumstances beyond our control, like license problems) were in force, I wouldn't have a problem. However, since the archive maintainers are adamant that the technical problem at issue be rectified by legislation rather than code, and since the Technical Committee agrees, there seems to be little point in continuing to argue. -- G. Branden Robinson|Kissing girls is a goodness. It is Debian GNU/Linux |a growing closer. It beats the [EMAIL PROTECTED] |hell out of card games. http://www.deadbeast.net/~branden/ |-- Robert Heinlein
Re: request for Technical Committee ruling on Bug #109436
On Fri, Aug 24, 2001 at 04:30:18PM -0500, Branden Robinson wrote: I'd like the Technical Committee to: 1) Tell me exactly how how rename and/or reversion my package; [...] Furthermore, if the Committee agrees with Jason's mail My thought, I need an answer from the archive maintainers on 1). [...] I'd recommend changing the version number to xfree86 (4.1.0+1-3) with xfree86_4.1.0+1.orig.tar.gz xfree86_4.1.0+1-3.diff.gz xfree86_4.1.0+1-3.dsc xlibs_4.1.0+1-3_i386.deb etc. It's the least obnoxiously different name I've seen (as compared to suffixing .dfsg-free, eg), it's the least effort on anyone's part (compared to changing the source package name which'd require other source changes and manual processing on the part of ftpmaster when it got uploaded), and it can disappear entirely when there's an actual new upstream tarball (as opposed to introducing an epoch), and it doesn't really seem likely to confuse anyone (oh, that's xfree86 4.1.0 with some minor difference). There also seems to be some precedence for that sort of versioning, see for example alsaplayer 0.99.36+1-1 or mozilla 2:0.9.3+0-1. All you need to do is change the name of the .orig.tar.gz so it's something different. If you want to make it xfree86_4.1.0.ftpmaster.sux.orig.tar.gz, well, I'm sure we can live with that. Personally, I'm still not seeing the objection to changing the version number, at all. The technical reasons why we don't want to overwrite files have been listed numerous times, and, as far as I've seen there's only be aesthetic (but the upstream version number *isn't* 4.1.0+1, it's 4.1.0!) and essentially bureaucratic (there ought to be a procedure for this, even if there's no need for it), neither of which seem like they should override even the limited technical objections that've been discussed. More worrying are the remarks that make this issue seem overly political and personal (The archive maintainers and I are deadlocked. I cannot think of a solution that involves neither them yielding nor me. and Sounds like that makes it unanimous against me.). I don't think that's any basis on which to discuss this issue. For reference, the .orig.tar.gz overwriting thing has come up on -devel in the past, see: http://lists.debian.org/debian-devel/2001/debian-devel-200101/msg01522.html for example. There's nothing personal in either the initial rejection, nor that we're not making any special exceptions. Also for reference, the current ftpmaster team is: * FTP Archives -- [EMAIL PROTECTED] member James Troup member Michael Beattie member Anthony Towns member Ryan Murray Personally, I'm ambivalent about the tech ctte's authority here. OTOH, since this does appear to have gotten bizarrely political and personal, getting the best technical solution (read: a new X uploaded with a fixed version number ;) looks like being best served by having the tech ctte adjudicate on it, rather than having more rounds of bug 109436 being closed and reopened, it might be better if ftpmaster just delegates their authority to the tech ctte on this. In any event, James Troup speaks for all of ftpmaster in that sense. Getting caught up in the constitutional aspects of the issue rather than the technical ones is just stupid, IMO. 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, 23 Aug 2001, Manoj Srivastava wrote: Why is it that Branden and I are the only ones worried about us violating copyright law? I haven't seen anyone say we are violating copyright law, the worst I've heard is that we have non-DFSG software in main which could mean many things.. Branden hasn't said exactly what files are the problem, etc. Jason
Re: request for Technical Committee ruling on Bug #109436
On Fri, Aug 24, 2001 at 03:45:06PM -0500, Manoj Srivastava wrote: After being repeatedly slapped with a wet trout, I have been convinced to change my views on this issue. (I'll refrain from reiterating what Raul, Jason, and Guy have already said before). Sounds like that makes it unanimous against me. I'd like the Technical Committee to: 1) Tell me exactly how how rename and/or reversion my package; 2) Revise the Debian Policy Manual to forbid the action I took, since it is not permitted. If you guys need to vote first, I'll wait until that is resolved. Manoj, I'd appreciate hearing from you privately on specifically what changed your mind; Guy proposed adding an epoch, which actually turned out to not be a solution at all, for instance. So it is unclear to me which statements in all of Raul's, Jason's, and Guy's mails are to be held as controlling here. Furthermore, if the Committee agrees with Jason's mail My thought, I need an answer from the archive maintainers on 1). The Policy Manual should be further amended to mandate that developers request and receive approval from the archive maintainers on how their packages are to be named and versioned. (It could probably be made part of the ITP process.) -- G. Branden Robinson| Q: How does a Unix guru have sex? Debian GNU/Linux | A: unzip;strip;touch;finger;mount; [EMAIL PROTECTED] |fsck;more;yes;fsck;fsck;fsck; http://people.debian.org/~branden/ |umount;sleep
Re: request for Technical Committee ruling on Bug #109436
On Fri, Aug 24, 2001 at 04:43:40PM -0600, Bdale Garbee wrote: I believe that we must have the ability to remove an orig.tar.gz and all derived objects from the archive under certain circumstances which have already been articulated by others. If the current toolset doesn't support that, it should be fixed. I agree. Once an existing orig.tar.gz and all derived objects have been purged, I can see no technical reason to require that a new upload use different filenames. We can't know who all is mirroring us, so we can never know when this process is truly complete. We're not talking about a single system here. -- Raul
Re: request for Technical Committee ruling on Bug #109436
[EMAIL PROTECTED] (Branden Robinson) writes: Sounds like that makes it unanimous against me. Nope. I actually disagree with the ftp admins on this one. I tried sending some comments out last night, not sure where they went... perhaps I mis- addressed the message or something. I'm away from home, and it was late after a long day. I believe that we must have the ability to remove an orig.tar.gz and all derived objects from the archive under certain circumstances which have already been articulated by others. If the current toolset doesn't support that, it should be fixed. Once an existing orig.tar.gz and all derived objects have been purged, I can see no technical reason to require that a new upload use different filenames. Since all of the tools that we use and care about that involve orig.tar.gz files check md5sums, and since the lamest mirroring tool I know of uses filename and modification date as the test for whether to copy something, I really can't see any negative side effects to allowing a replacement package to be uploaded with the same filenames after a purge has occurred. Having said all that... Uploading a new orig.tar.gz with a tweaked upstream version number clearly isn't onerous. While it should not be necessary, if the current archive management toolset can't do the right things, were I Branden I'd get on with uploading an orig.tar.gz with new filename and move on to the next issue. Bdale
Re: request for Technical Committee ruling on Bug #109436
On Sat, Aug 25, 2001 at 12:05:10PM +1000, Anthony Towns wrote: It means you can find yourself downloading an .orig.tar.gz from the right place with the right name from one non-corrupt Debian mirror, and a .dsc from another and ending up with the md5sum of the tarball not matching the md5sum listed in the .dsc. Or even from the same mirror if, for instance, the .dsc info is downloaded before the source tarball. -- Raul
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)
