Re: request for Technical Committee ruling on Bug #109436
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.
> I cannot think of a solution that involves neither them yielding nor
> me.
I understand.
> > And, for that matter, the part of 6.3(5) that ends "reasonably
> > thoroughly discussed elsewhere".
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.
Nor does it look like there was much of an effort to achieve a
consensus.
> > Also, consider that if we do take this on, we'll probably make our
> > decision on technical grounds, and so far you've not given any for
> > your proposal.
>
> You appear to be construing "technical grounds" as anything the archive
> maintainers have to do, and nothing the package maintainer has to do.
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.
> Please provide me with a definition of "technical grounds" that is
> operative for you.
Technical grounds, in this context, refers to software design issues.
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.
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?
> > Instead, you've mostly been focusing on issues of precedent.
> > Precedent, to us, mostly matters in the context of questions like
> > "what breaks?", "what does this enable?", and "what do the specs
> > say?"
>
> "What breaks?" The archive, if its administrators neither have code to
> accomodate the situation in question, nor handle it manually.
Agreed.
I don't think breaking the archive is a good thing. Do you?
> "What does this enable?" If .orig.tar.gz changes after dinstall are
> always forbidden, nothing. It relieves the archive maintainers of ever
> having to handle situations like mine. If .orig.tar.gz changes after
> dinstall are permitted, it enables package maintainers to make changes
> to the .orig.tar.gz when necessary, in ways that don't disrupt the
> continuity of the package's naming or versioning.
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.
[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.
[3] extra chatter. Not only this discussion, but future
discussions brought on by the above issues.
I don't think these are good things. Do you?
> I can already hear your objection, so let me ask you if you would
> consider a hypothetical situation where the "glibc" source package
> changed its name and versioning scheme (requiring an epoch in the
> Debian version) with every upload. Is that scenario a "technical" 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 this hypothetical situation did wind up in my face, I'd probably
be advocating that the glibc maintainer used a systematic scheme
[probably a suffix] to deal with whatever it was that he felt he
needed to deal with.
> > > If I'd been aware of xc/util/patch's licensing before I released
> > > 4.1.0-1, I would not have included it. The same goes for every
> > > previous release of XFree86 I have made.
> >
> > None of us know everything.
>
> 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.
> > You are correct. They're giving you more latitude than I would have
> > been.
>
> This does not sound like an objective remark from someone who is
> supposed to be acting in a neutral capacity.
"I would have" refers to the stuff I'd written which you had just
responded to. You didn't quote that text here, but it's what I was
talking about.
> > > Such a Policy is neither present, implicit, nor precedented, since
> > > in the past it was perfectly possible to change an .orig.tar.gz by
> > > simply uploading a new one and referencing it accurately in a .dsc
> > > file.
> >
> > D.2.12 defines the part of the old .dsc file which you're breaking.
>
> I cannot agree with this reading of D.2.12 (which we should both note
> -- since it is part of the appendix to the Debian Policy Manual -- is
> not binding on developers since it hasn't been brought up to date;
> but, for the sake of argument, I'll pretend that it is).
Are you pretending that policy is the only relevant specification for
this context?
> It says "In the .dsc (Debian source control) file each line contains
> the MD5 checksum, size and filename of the tarfile and (if applicable)
> diff file which make up the remainder of the source package."
>
> We can probably agree that neither the old nor the new .dsc files are,
> or need be, syntactically invalid to accomodate the end I am seeking.
It's the validity of the md5 checksum for the filename that I'm obviously
talking about.
> It further says "If a new Debian revision of a package is being
> shipped and no new original source archive is being distributed the
> .dsc must still contain the Files field entry for the original source
> archive package-upstream-version.orig.tar.gz, but the .changes file
> should leave it out. In this case the original source archive on the
> distribution site must match exactly, byte-for-byte, the original
> source archive which was used to generate the .dsc file and diff which
> are being uploaded."
Yep.
> What I am doing is shipping a new Debian revision of a package *and*
> distributing a new original source archive. Therefore it is not
> required that the original source archive on the distribution site
> match exactly, byte-for-byte, the original source archive which was
> used to generate the .dsc file and diff which are being uploaded.
True: people do this all the time.
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.
> > 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.
> > 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?
> > If the ftp admins have gotten around to implementing any kind of
> > integrity checks in place (where files with improper md5sums are
> > not propagated), the way to do what you ask could involve manually
> > deleting every copy of xfree86 4.1.0 off of every official mirror
> > before uploading your new copy. And this might still hose unofficial
> > mirrors.
>
> I do not see how this is any different from mundane cases of archive
> corruption. As long as the katie database, which contains the proper
> md5sums for each file, is updated to reflect the change in the
> canonical file, I see no *technical* reason why changes to existing
> files are impermissible.
Archive corruption is localized: it doesn't suddenly invalidate every
previously valid copy on several dozen mirrors. Furthermore, with
archive corruption, you can take any machine where the md5sum
matches the file contents and use that to fix the broken archive.
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.
> And, if you'll recall my original mail, I was not asking for the new
> .orig.tar.gz to be dropped into the archive with no other action
> taken.
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.
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.
> > Is that what you want? This might take several weeks, or longer.
>
> What about cases where we have to yank an .orig for legal reasons? Does
> it take several weeks to propagate the file removal? Is the mirrors'
> exposure to liability our problem or theirs?
Obviously it depends on the urgency. However, it's usually sufficient
that you're taking reasonable steps to rectify the situation.
> 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?
> 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.
Which pretty much sums up most of this thread.
FYI,
--
Raul
Reply to: