[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 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.
branden@deadbeast.net              |       -- Oscar Wilde
http://www.deadbeast.net/~branden/ |




Reply to: