Re: request for Technical Committee ruling on Bug #109436
On Fri, Aug 24, 2001 at 06:49:01PM -0400, Raul Miller wrote:
> So far:
>
> Admin solution: tarballname,md5sum relationship is constant once
> established.
>
> Branden solution: tarballname,md5sum relationship varies based on
> maintainers preference.
Incorrect.
Branden solution: tarballname,md5sum varies if Debian Policy forces the
maintainer to change it after it's been established.
> However, as I've already pointed out, the existing documentation could
> easily be taken to imply such a requirement.
I don't believe this follows.
> 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.
No, I'm saying that I had no way of knowing a prori that the old
interface was actually a bug. It was the interface that was exposed to
me as a developer.
You say it's a bug, I say it's an interface. Because the documentation
was unclear, there may be no way to objectively decide the matter.
Appealing to the authority of the archive maintainers, past or present,
doesn't do any good if they didn't communicate their unenforced
requirements to the users of the archive.
Consider this analog:
master.h:
int ftp_interface(int value);
master.c:
int ftp_interface(int value) {
#ifdef NEW_VERSION
if (value < 0 ) {
fprintf(stderr, "Sorry man, that's crap.\n");
return 0;
}
#endif
return 1;
}
At some point, the builders of this "master" library #define
NEW_VERSION, but the library's documentation about negative values was
never documented anyplace.
Of course, if you asked one of the developers about master.c on IRC,
they probably would have told you the restriction was there, just not
enforced yet...
> 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".
Debian User: "Why aren't all the other packages called <foo>-source? I
see this pine-src thing, is that the same thing? Do I have to build
XFree86 from scratch on my box just line pine?"
> 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.
How was I to know a priori that the behavior wasn't deliberate? The
only documentation I had were the Policy Manual, the Packaging Manual,
and the Developers' Reference.
I've already explained how D.2.12 doesn't tell you can't upload a new
Debian revision of a package with a new original source archive. D.2.12
doesn't address when .orig.tar.gz files should or should not be
uploaded, just how to manage your .dsc and .changes files when you do or
do not include .orig.tar.gz's. C.3 doesn't address this either.
> 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.
In fact, it is *because* the Policy Manual is telling me what I can and
cannot do that this change to the .orig.tar.gz was made in the first
place.
> 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.
> 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."
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.
> 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.
If "apt-get source" notes an md5sum mismatch, it downloads a new version
of the file.
If somebody tries to "apt-get source xfree86" before this change
happens, they get 4.1.0-2 plus the source tarball with non-free code in
it. If somebody tries to get "apt-get source xfree86" after this change
happens, and they haven't apt-get updated yet, they might get told that
the package is not available. This is not pathological and not unique
to the situation I'd be causing; source packages fall out of the pool
all the time. If someone tries to get "apt-get source xfree86" after
this change happens and they've apt-get updated, they get 4.1.0-3 plus
the source tarball without the non-free code in it.
If they already have part of the source package downloaded, apt will
verify the md5sums of the files against those reported in the Sources
files. If there is a mismatch, apt-get will re-fetch the files that
don't match up -- it doesn't choke.
If our mirrors are operating correctly, they will not have Sources files
that do not correspond to the contents of their archive mirror.
If our mirrors are operating incorrectly, that's not germane to the
current issue.
> 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?
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. Either mirrors are up to date or they are not. 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 agree that the docs and policy should be updated to explain this
> issue more clearly.
Thanks.
> 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.
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.)
> "Should I take this to mean that you've stopped beating my wife?"
I think you misinterpreted the question.
> > > 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.
No, it's not. Please see above. D.2.12 doesn't say a maintainer can't
change the contents of an .orig.tar.gz without changing the filename.
No piece of Debian documentation that I have been able to find,
normative or descriptive, says this.
> 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.
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.
For resources other than mirrors, I've explained why apt-get source
doesn't pose a problem.
> Again, this has to happen on all machines with debian sources before
> you can safely propagate the new file.
I don't see why, unless the mirrors refuse to accept the .orig.tar.gz on
the reference site as canonical. As I said, I get 404's on .deb
downloads with apt the time.
> > 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.
> 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).
How and what package maintainers upload to an official incoming queue
isn't a technical issue?
> 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.]
If I'm going to be told to change the name, I ask that I be told exactly
what to change it to do.
> 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.
I don't believe I've expressed any preferences about how I rename or
re-version the package. If you think I have, please direct me to the
message.
> > 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.
I would presume that the archive maintainers would make a good-faith
effort to ensure that the packages which package maintainers upload get
installed.
> Please explain to me what problems they'll experience if you rename the
> source package to xfree86-sources.
See above.
> If we lose ftp-master, entirely, we'll choose another machine which
> has been mirroring it to serve in its place.
What if you lose ftp-master entirely in the middle of a mirror pulse?
If you don't, what difference does it make?
> > 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?
It's not important to you that package maintainers know where to upload
their packages? If I had permissions to upload to ftp.eecs.umich.edu,
should I expect the package to get into the Debian archives from there?
> 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
No. I'll say it again. D.2.12 doesn't address when .orig.tar.gz files
should or should not be uploaded. It tells the package maintainer how to
manage his .dsc and .changes files when he do or does not include
.orig.tar.gz's.
> [b] conflicts with a variety of potential integrity mechanisms, and
You don't like hypotheticals; neither do I. Can you identify some *real*
integrity mechanisms with which it conflicts?
> [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.
I've already acknowledged that the handling of this sort of issue, at
present, requires manual intervention. However, you seem to keep
overlooking the fact that it is Debian Policy which prompted this change
in the first place. You keep bandying about the word "whim" when
referring to my preferences in this matter, but if it's all the same to
you I'd rather not change the source .orig.tar.gz at all. In any way.
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.
> Your "step-by-step descriptions" gloss over all these issues.
No. I've addressed D.2.12 multiple times, and I've been addressing the
issues of integrity mechanisms (the katie database needs to be updated),
and manual intervention (a person needs to update the katie database)
from my very first mail to the Technical Committee on this subject.
> > 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.
"It's a hypothetical one. It's not one for this committee unless
other developers have problems with it."
"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."
Maybe "exhortations" is too strong a word. I interpret the above to
mean "these types of argument aren't convincing me, try something else".
If I expect to persuade you, it's a waste of my time to apply approaches
that you've already told me you'll reject.
> I'd prefer we take this off-list, if it turns out that I said something
> I didn't intend, I'll apologize publicly.
I am rapidly reaching the conclusion that it is beyond my power to
convince you to change your mind on this point, so I don't see what
purpose off-list discussion will serve. I will continue to answer
questions you put to me, and I will speak if I feel you misrepresent the
situation or my arguments to the other members of the Technical
Committee.
> > As I am asking the archive maintainers now to take reasonable -- not
> > unreasonable -- steps to accomodate my request.
>
> They appear to be unreasonable steps.
[...]
> 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.
I conclude from the above that you feel it is unreasonable to expect the
archive maintainers to do anything at all (aside from let the da-katie
machine churn) when a license or copyright problem is found in an
.orig.tar.gz. If this is incorrect, under what specific circumstances
*do* you expect them to act? How quickly is a package maintainer
supposed to react when informed of a license or copyright problem in a
source package? Is putting off the resolution until the next upstream
release acceptable?
> > 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.
I don't think this should stop you from talking to them about it.
> > 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.
Just in case you're about to get carried away here, what I'm saying is
that the my proposed resolution of this matter does not *increase* Debian's
liability or exposure on copyright or other grounds with respect to this
source package, any worse than it already is with the archive in its
present state.
> 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.
I have provided you with a very great deal of information, and you seem
to regard most of it as worthless. So either I'm being evasive, you're
not asking the right questions, or there is no information I can give
you that you would regard as meaningful.
> 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.
I filed one against ftp.debian.org. The maintainers didn't want to fix
it.
--
G. Branden Robinson | Q: How does a Unix guru have sex?
Debian GNU/Linux | A: unzip;strip;touch;finger;mount;
branden@deadbeast.net | fsck;more;yes;fsck;fsck;fsck;
http://www.deadbeast.net/~branden/ | umount;sleep
Reply to: