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 plausible interpretations. Ordinarily, that means the developer has discretion, or that the Policy Manual is too vague and needs to be fixed. I know you've already agreed that the latter needs to happen; what I'm saying here is that not everybody in the world reads rulebooks the way you do. So I don't think you should assume that people are ignorant, misguided, or stupid when they do. > > > The package maintainer determines what contents go in what file name, > > > > No, actually Debian Policy decides a great deal of this automatically, > > as does C.3. > > That's not a contradiction. It is. It is a constraint on the package maintainer's power to "make any technical or nontechnical decision" with regards to his packages. It constrains his options. Nobody said the Policy Manual was a bad thing for doing. It's a very useful and powerful tool for ensuring that we have a quality distribution that doesn't needlessly frustrate our users. It's also a work in progress, and probably always will be. > Sure, and if you want some help seeing problems with our current policy, > consider http://cr.yp.to/compatibility.html ... of course, that point > of view assumes that the upstream authors are the package maintainers, > but hey, that's not such a bad idea, is it? We're totally off topic, but I disagree with djb's analysis on that page. Moses didn't come down from the mountain in 1970 and give Dennis Ritchie and Ken Thompson a copy of the FHS. > That said: if we do it your way, we break the release of all software > which has been built against 4.1.0. That's simply not correct. "My way" is an end, not a means. I'm willing to work with the archive maintainers to help them come up with a good means, but since they know the archive better than I do, I'm willing to defer to their judgement on issues that don't impact my package. The debian/control file in my package is my province. Where I am constrained, it must be by Policy or the packaging system, not by the heretofore unwritten rules of the archive maintainers. > If we do it the admin way we break almost nothing or nothing. We can defer to the archive maintainers in all issues great and small, if we choose. However, the Constitution recognizes the soverignty of the package maintainer. This sovereignty isn't some sop thrown to them, or a nuisance. It's how you get volunteers to remain enthusiastic and motivated, and take some pride of "ownership" in their package, so that they do a good job and contribute goals to the whole. > > > but the package maintainer can't change their mind once the files > > > have been distributed (because at that point the package maintainer > > > no longer owns all instances of the file). > > > > I didn't change my mind. The Debian Policy Manual did it for me. > > Take some responsibility for your own actions. Funny, I'd expect to be called irresponsible for leaving a Release-Critical bug open on my package because I didn't think it was important enough to fix it, not for taking action with the very next package upload. > > Why do we need to? We change the canonical version of > > xfree86_4.1.0.orig.tar.gz on the canonical site and tell the mirrors to > > mirror it. > > And what about people with slow modems who only update occasionally? Uh, uploading xfree86-foobar-4.1.0.orig.tar.gz isn't an equally great burden? (Okay, yanking xc/util/patch saved a few kilobytes, I'll grant you that.) > Also, what about Wichert's point? See above. > After that: they wait for however many hours for the thing to download, > then get told that the download failed. I hate to inject practicality back into this, but exactly *how* much sense does it make for somebody with a slow modem to be both tracking unstable *and* downloading the 55 megabyte X source tarball as a matter of course? Such people, if they exist, must be possessed of such superhuman patience that I'd wager they wouldn't be fazed by the tragedy you describe. That, or they'd use rsync. > You're assuming no integrity checks along the line of what katie does > at any of our mirrors. That's not reasonable because there's huge race > condition windows while stuff is getting transfered, and if it's not > installed in an orderly fashion we expose the users to more problems > than are necessary. > > [Ok, we have mirrors which are running without such checks, but that > doesn't mean it's right.] Is ftp-master considered canonical, or is it not? If the archive maintainers are willing to implement a solution that appears atomic with respect to the daily mirror pulse, as I proposed above, I don't see how things could break, unless the mirror was *already* broken. > > I get 404's from mirrors all the time, on files that comply with archive > > maintainers' requirements to a T. It's aggravating. I don't know if > > they feel this desynchronization is a problem; I'd be thrilled to see it > > fixed. The problem is not made substantially worse by accomodating my > > request. > > I disagree. Define how it's substantial. How many times since the package pools went into effect has this issue come up between me and the archive admins? How many megabytes of Debian packages have I pushed through the pools without such an incident? (I'd refer to other developers as well, but I know my own history best.) > > Either mirrors are up to date or they are not. > > Or they're being updated, such that all integrity checks are satisfied > at each step of the way. Not a problem, with the solution proposed above. > > I am not advocating that ftp-master be put into a half-assed state > > to accomodate my source package. Let's please not beg the question > > by asserting that a changed .orig.tar.gz along with updates to katie > > database is to be defined as a half-assed state. Otherwise I truly am > > wasting my time here. > > I think that's exactly what I'm saying. Which of the 3 sentences are you agreeing with? That I'm wasting my time? > > Incorrect. The burden's on the archive maintainers. Are you an archive > > maintainer? (I don't actually know who is, beyond James Troup, Ryan > > Murray, and Michael Beattie.) > > If we tell them to change what they're doing, we're responsible for the > imlications of that decision. Yes. The same goes if you tell package developers to change what they're doing. These are your burdens to bear as a member of the Technical Committee. [D2.12 analysis snipped. I agree that there's more than one set of possible implications.] > > Pretty easy if we nuke 4.1.0-[12] from the archive. If the mirroring > > software is sound and there aren't network problems, it's a mirror > > site admin's responsibility to make sure that his mirror stays in sync > > with the reference site. > > I don't think it's as easy as you say. I've said time and time again that I'm willing to work with the archive admins to meet whatever criteria they need with regards to handling my request as cleanly as possible. > And I've explained why it does (modem users, conserving bandwidth, > wastes umpteen hours of download time -- remember that in much of the > world bandwidth is limited and expensive). These aren't problems that are exacerbated any more by my request than they are by regular uploads of X, or any large package. Perhaps you're doing these folks a favor by helping to slow down my release rate? > > > > You said I was violating Policy. I pointed out that I wasn't. > > > > > > You did no such thing. You talked at length without bringing up > > > the issue we're talking about. > > > > Then I guess you'll have to remind me. These mails have gotten huge. > > Discussion of D.2.12 -- you spent many paragraphs not talking about > the case of what it meant in the context of two different packages, > two different source packages, same file name. But context is what this > discussion is all about. I think I have addressed this above. 1) Timestamps. 2) There are not two authoritative md5sums for the same file at the same time. > > If the Technical Committee will grant me immunity from prosecution for > > this violation of Policy, I'll go away a happy man, and fix the problem > > in 4.2.0. > > For that, we'd need a lot more detail on the DFSG violation. > > Can you provide a pointer for the bad patch license? Also, wasn't patch > written by Larry Wall? You might just try asking him for permission to > distribute it under some DFSG copyright. "You may copy the patch kit in whole or in part as long as you don't try to make money off it, or pretend that you wrote it." That's the license. > But if what you say shows that you've not even considered the potential > problems, and then you say [paraphrasing] "it's not my responsibility, > this is the way I've alway done it and I like it this way" ... well... > .. um.. I guess that class of approach doesn't seem to solve much > of anything. It's the same one the archive maintainers are using. How I rename my package isn't their problem, rejecting the kind of upload I made is the way they've always done it (since pools were implemented), and they like it that way. > I'd like to at least read the copyright on this old patch before saying > much more on how slow it's reasonable to be here. If you can provide a > pointer, I'll go look it up. Otherwise, I'll need to find a few hundred > megs of free space and plow through the sources myself. See above. -- G. Branden Robinson | The only way to get rid of a Debian GNU/Linux | temptation is to yield to it. [EMAIL PROTECTED] | -- Oscar Wilde http://www.deadbeast.net/~branden/ |
