Re: request for Technical Committee ruling on Bug #109436
On Fri, Aug 24, 2001 at 04:18:08PM -0500, Branden Robinson wrote:
> What technical points regarding my package or its upload do you need
> further clarified?
Basically: I need to make sure that all the problems which would be
experienced by the admin folks with your proposal have good solutions and
that we're not going to be creating ongoing problems for lots of mirror
maintainers. That means starting with a list of all those potential
problems, and then making sure that each of them has a satisfactory
solution.
I also need to make sure that all the problems which would be experienced
by you, with the admin proposal have good solutions, and that we're
not going to be creating ongoing problems for you. Again, that means
starting with a list of all those potential problems, and then making
sure that each of them has a satisfactory solution.
Of course, things that wind up in the technical committee have typically
degraded to the point that we can't get a completely satisfactory solution
to all issues, but we try as best we can.
> > 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.
>
> Because something is easy doesn't make it correct; I was under the
> impression that the Technical Committee is charged with finding
> solutions that are as technically sound as possible, not necessarily the
> most expedient ones.
That's exactly why we're having this discussion.
So far:
Admin solution: tarballname,md5sum relationship is constant once
established.
Branden solution: tarballname,md5sum relationship varies based on
maintainers preference.
> I'll admit, however, that I don't think the Constitution explicitly
> places that burden on the Technical Committee. If my expectation is
> unreasonable, please tell me.
What do *you* mean by technically sound?
Basically, it seems like the job of the technical committee is to tell
people not to break things. Or, if we don't do our job well enough,
it's our job to come up with a solution once things are broken beyond
hope of repair.
And, right now, it's looking like you want to break the archives to hide
one of our mistakes. [Not yours, personally, but ours collectively --
this should have been caught by the xfree folks, or could have been
caught by any one of debian's users.]
> > Technical grounds, in this context, refers to software design
> issues.
>
> What technical grounds exist on which you require further explication,
> and am I the best person in this particular dispute to elucidate them?
You tell me.
Right now you're doing an adequate job of convincing me that no such
grounds exist.
> > 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.
>
> I agree. The archive maintainers did not do so when they implemented
> this new rule of "no changes to .orig.tar.gz's after their initial
> install." There continues to be no documentation of this requirement.
Sounds like a bug: file a wishlist bug report against ftp.debian.org
asking for documentation. If you haven't done this by some time next
week, I think I'll do it.
However, as I've already pointed out, the existing documentation could
easily be taken to imply such a requirement. That this requirement
wasn't enforced before could also be taken as a bug. [A fixed bug.]
> You are telling me that interfaces are sacred, and that you shouldn't
> change them, and citing this as a principle of software design that
> comprises technical grounds, but at the same time you've dismissed
> much of my case as being founded on precedent, not valid technical
> grounds.
Right: you're saying, in essence, that the undocumented historic practices
of upstream represent an interface.
I'm asking: why should we consider these an interface rather a bug?
Your response is that you like it that way, and that's the way it's been.
To me, that seems like a whim, not a reason. We hang onto historical
bugs if fixing them means breaking something else. But I don't see that
fixing this bug breaks anything.
But, I'm still willing to be convinced, if you're capable of doing so.
You can start by telling me what's wrong with "xfree86-sources", besides
"it's ugly, it's different, it's not what I want".
> Uploading a changed .orig.tar.gz used to work with the old interface
> to the Debian package archive. It does not now. The interface changed.
The implementation was broken, because we had files that didn't match
their md5sums. That bug has been fixed. You've been relying on
undocumented behavior.
> > 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?
>
> I don't see how you're applying the "single point of control" maxim
> here, unless it's to say that the archive administrators should be the
> single point of control for package filenames and contents, and not
> the package maintainer.
The package maintainer determines what contents go in what file name,
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 don't think breaking the archive is a good thing. Do you?
>
> As you may have gathered from my previous mails on the subject,
> I'm not asking for the archive to be broken. I'm asking for it to
> accomodate the changed .orig.tar.gz in a functional and correct way.
There is no correct way, in the general case.
Once again: you're asking us to hide the problem. If we do it your
way, we'll never be able to put up a page that says:
"Sorry, xfree86_4.1.0.orig.tar.gz contained code which
we didn't have full rights to. Please replace it with
xfree86-sources_4.1.0.orig.tar.gz. The code in question
is not used in any debian binary packages."
> > 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.
>
> In practice, users report issues with source packages -- as opposed
> to source files -- in Debian. The version number on a source package
> is sufficient for anyone to discern which .orig.tar.gz is being
> referenced, even under the unusual circumstances I am saying should be
> permitted.
>
> Nowhere am I requesting that a given .dsc be permitted to refer
> incorrectly to an .orig.tar.gz, unless the archive maintainers deem
> that such breakage can be tolerated on a temporary basis.
You're pretending that the .dsc files which are already out there don't
exist, and you're pretending that you know every situation which will
be reported by users.
> > [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.
>
> Valid situations like what? I'm perfectly willing to grant that
> changes to .orig.tar.gz's should only take place when there are legal
> issues with distribution, license problems (like DFSG-violations), or
> where the developer is otherwise compelled by Debian Policy to change
> the .orig.tar.gz. (DFSG-compliance is the only scenario of which I am
> aware where Policy makes such a requirement.)
Valid situations like .dsc and .orig.tar.gz file are transferred
at different times.
Do I have to define "race condition" for you and lecture on the subject?
> > [3] extra chatter. Not only this discussion, but future discussions
> > brought on by the above issues.
>
> Easily rectified, or at least greatly ameliorated, by documenting the
> policies that are actually in force, and by documenting changes to
> upstream source tarballs in debian/copyright and debian/changelog as
> is already required by policy.
I agree that the docs and policy should be updated to explain this
issue more clearly.
> > I don't think these are good things. Do you?
>
> I don't think that rubber-stamping the decrees of the archive
> maintainers is the only way to avoid these, nor necessarily the best
> one.
But you've said:
I don't think the burden is on me to explicate the difficulties that
the archive maintainers have in accomodating my request, though I
have attempted to summarize to the best of my knowledge.
You're right. The burden's on me. But I don't have a good answer.
> > 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 hypotheticals are verboten, then can I ask *you* to stop using
> them?
Hypotheticals are not verboten -- you introduced a what looks like a
non-problem, but since it was a hypothetical it's actually a whole field
of potential situations, not a specific problem that can be solved.
> > > 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.
>
> Can I ask *why* the Technical Committee feels that I am maintaing the
> package in a substandard or irresponsible manner?
"Should I take this to mean that you've stopped beating my wife?"
"No."
"Can I ask *why* you're beating my wife."
"I'm not: that's just not what it meant."
> > Are you pretending that policy is the only relevant specification for
> > this context?
>
> Can you quote any other specification that's on point?
You mean besides D.2.12?
I suppose documentation on what md5sum means is relevant.
> > It's the validity of the md5 checksum for the filename that I'm obviously
> > talking about.
>
> And it won't ever be invalid, if when replacing an .orig.tar.gz in the
> archive, you:
> * update the katie database
All instances of the information in the .dsc and .changes files from
4.1.0-1 must be purged from all machines [in the entire world] which
store this information.
> * purge the older versions of the package that used that source
> tarball
Again, this has to happen on all machines with debian sources before
you can safely propagate the new file.
> * accompany the changed .orig.tar.gz with a new Debian package
That's the easy part.
> > 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.
>
> 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.
> It has been my contention from the very beginning that *if* the
> archive maintainers are "correct" in this matter, that the Debian
> Policy Manual needs to be amended to tell package maintainers about
> these new things they can't do.
I don't disagree with that.
> I'd point out that in the past it was possible and legal for package
> maintainers to do what I did with my 4.1.0-3 upload, but you said
> earlier that you weren't interested in precedent.
You're misquoting me.
I said that I was interested in precedent where it had to do with
technical issues (the ones I raised were specifically focussed around
release management).
> > > > 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.
>
> If the Technical Committee is going to rule against me, I'd like to know
> which is preferred:
>
> * changing the source package name
> * changing the source package version number
> * changing both
Personally, I don't care. And, if the technical committee makes a
general ruling, we probably won't pick a specific name. [I'm guessing.]
Based on what you've said to me about your preferences, I'd recommend
that you change xfree86 to xfree86-sources, and that you leave the
version number alone.
> Furthermore, I think the Technical Committee should propose
> (or decree, since I think they're empowered to do so) some
> Policy governing situations like mine so that this issue is less
> contentiously resolved next time.
*sigh* yeah.
> > > > 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?
>
> Clause 3.1.1 of the Constitution isn't enough for you?
It's good enough for me if you don't care whether the ftp admins reject
it because you've already made a different decision.
> Besides, given a choice between confusing our users and confusing the
> archive maintenance software, I'll choose the latter every time unless
> there really is an intractable problem at hand.
>
> If you disagree, I'd refer you to article four of the Social Contract.
Please explain to me what problems they'll experience if you rename the
source package to xfree86-sources.
> > 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.
>
> Except that if there are any plans to consider mirrors authoritative
> over ftp-master under any circumstances, I'd like to hear about them.
If we lose ftp-master, entirely, we'll choose another machine which
has been mirroring it to serve in its place.
> This would probably be news to the developers and mirrors as well,
> since the only way at present for the authoritiative version of a
> package to get into the archive is via upload to an official archive
> server that runs the katie software.
So?
> > 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.
>
> Quoting one sentence out of hundreds of lines of email I've written on
> this subject -- including step-by-step descriptions I made of changes
> that would need to take place on the archive to fulfill the above (as I
> understand it), is not a fair or complete presentation of my argument.
You're asking the ftp admin folks to accept, as POLICY, a practice which
[a] conflicts with the idea that D.2.12 has anything other than fleeting
significance, and
[b] conflicts with a variety of potential integrity mechanisms, and
[c] requires that the current software and procedures be bypassed using
some kind of manual intervention.
[a], and [b] are my reasons for thinking that your proposal is technically
not the right thing to do, and [c] is the proverbial nail in the coffin.
Your "step-by-step descriptions" gloss over all these issues.
> > 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.
>
> I've discussed them at length. You have reduced my entire
> participation in this exchange to one sentence and are attacking it as
> one would a straw man.
I'll agree with the "at length" part.
> Furthermore, as you are exhorting me to refrain from using
> hypotheticals or citing precedent in my argument, and stick to
> technical grounds, I'd ask you to refrain from arguing abstractions
> when concrete discussion of the archive maintenance software will
> suffice to clarify the present situation.
You've misunderstood what I wrote. If you think that's what I said,
please quote back to me the relevant paragraphs.
I'd prefer we take this off-list, if it turns out that I said something
I didn't intend, I'll apologize publicly.
> > Obviously it depends on the urgency. However, it's usually
> > sufficient that you're taking reasonable steps to rectify the
> > situation.
>
> As I am asking the archive maintainers now to take reasonable -- not
> unreasonable -- steps to accomodate my request.
They appear to be unreasonable steps.
> > > 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?
>
> I do not think that my pointing out that there are other situations
> which may require manual intervention on the part of the archive
> maintainers is the same thing as saying that all possible situations
> are the same as some worst-case scenario.
Nor does pointing out that there are cases where manual intervention
is required mean that your situation is equivalent to those cases.
> Where, indeed, did I even *mention* worst-case scenarios? Why are you
> concerned about them? Is it your preference that the archive
> maintainers be required to act manually *only* in worst-case scenarios?
Ideally: yes.
> If so, I think you underestimate both the current and planned levels
> of automation of the archive maintenance software, though I would
> certainly not presume to speak in lieu of the archive maintainers
> themslves with regards to their future plans. As I've said before many
> times, it might be worthwhile to ask them.
I'm all too aware of the frailties of communicating systems.
> > > 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.
>
> I am pointing out that granting my request imposes no "worst-case"
> scenarios upon us or our mirrors with regards to license compliance or
> illegal code.
Sure, and that's a good thing.
> I should think that's an important consideration; were my request to
> necessitate such a consequence, I would expect it to be denied.
Ok.
> > Which pretty much sums up most of this thread.
>
> Nevertheless, I continue to ask the Technical Committee to issue a
> ruling.
Personally: I'm not going to make a proposal before I've exhausted
the possibility that you're capable of providing us with some actual
meaningful information relevant to this topic.
And, on the other hand, if the entire matter can be cleared up with a
couple of bug report filings, I'm not sure I see what we are deciding on.
If you insist, I suppose I can try to think of voting on a proposal
counter to yours as a courtesy to you.
--
Raul
Reply to: