Re: request for Technical Committee ruling on Bug #109436
On Fri, Aug 24, 2001 at 12:12:27PM -0400, Raul Miller wrote:
> 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.
>
> That would mean that you won't be submitting any useful packages for X
> 4.1.0.
No, it means that the archive maintainers won't be accepting them.
> On Thu, Aug 23, 2001 at 04:29:51PM -0500, Branden Robinson wrote:
> > Is it your opinion that the logs of bug 109436 do not qualify as a
> > reasonably thorough discussion of the issue?
>
> Looking at it from a technical point of view (in terms of software
> design issues), no -- I don't think it's reasonably thorough.
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.
What technical points regarding my package or its upload do you need
further clarified? If there are none, and you find the discussion still
wanting, then I assume the unexplored points have to do with the archive
maintainers and their software, in which case I urge you to consult with
them on these issues, not me.
> Nor does it look like there was much of an effort to achieve a
> consensus.
I agree. I was presented with an ultimatum; "do it how we tell you or
your package can sit in Incoming forever. Sorry, have a nice day, don't
let the door hit you in the ass in the way out."[*]
> 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.
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.
> 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?
> 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.
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.
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.
> 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.
> Agreed.
>
> 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.
> 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.
> [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.)
> [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 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.
> 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?
> > 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?
> Are you pretending that policy is the only relevant specification for
> this context?
Can you quote any other specification that's on point?
> 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
* purge the older versions of the package that used that source
tarball
* accompany the changed .orig.tar.gz with a new Debian package
> 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.
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'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.
> > > 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
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.
> > > 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?
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.
> 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.
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.
> 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.
> 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.
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.
> 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.
> > 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.
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?
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.
> > 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.
I should think that's an important consideration; were my request to
necessitate such a consequence, I would expect it to be denied.
> Which pretty much sums up most of this thread.
Nevertheless, I continue to ask the Technical Committee to issue a
ruling.
[*] no, that's not an actual quote
--
G. Branden Robinson | One man's "magic" is another man's
Debian GNU/Linux | engineering. "Supernatural" is a
branden@deadbeast.net | null word.
http://www.deadbeast.net/~branden/ | -- Robert Heinlein
Reply to: