Re: request for Technical Committee ruling on Bug #109436
> On Thu, Aug 23, 2001 at 03:25:09PM -0400, Raul Miller wrote:
> > You do understand that this isn't a technical issue?
On Thu, Aug 23, 2001 at 02:58:25PM -0500, Branden Robinson wrote:
> It is, however, an issue upon which the Technical Committee is empowered
> to rule:
I understand that. However, consider also 6.3(6). And, for that matter,
the part of 6.3(5) that ends "reasonably thoroughly discussed elsewhere".
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.
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?"
> > We're talking about a new version of the source tarball.
>
> Correct, if you are referring to file contents.
Yes.
> > You're saying that the new version isn't very different from
> > the old one, and that the old one should never have existed.
>
> 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.
> > On the other hand, the old one does exist. The admin folks are
> > saying: if you don't want the old version, use a new version.
>
> I hesitate to speak for the archive maintainers, but I don't think
> they're saying exactly that. They're saying "if you want a new version,
> rename the file."
You are correct. They're giving you more latitude than I would have been.
> > We need explicit policy that says "any change to the source
> > tarball requires a new version number"?
>
> 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.
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".
> So, yes. If that's how the Technical Committee rules, that's what we
> need. I would argue that the new policy should not be categorical
> about it.
Do you see any flaws with the sentence I just now proposed?
> I do not think Policy should compel me to both change my .orig.tar.gz
> ASAP and at the same time compel me to perpetrate some kludge upon its
> name and/or version, when such a change is not otherwise pending.
>
> To further elaborate, I would be satisfied with a Policy that said
> maintainers are not allowed to change an .orig.tar.gz that exists
> in the archive *unless* they're compelled to do so by some other
> aspect of Debian Policy. I think it quite reasonable for the archive
> maintainers to not want developers to go changing .orig.tar.gz's on
> a whim (because it can cause problems, as they have pointed out). I
> do not think it is reasonable for the archive maintainers to have
> an urwritten policy that effectively attributes all changes to
> .orig.tar.gz's to developer whims, meriting rejection of the change.
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.
Is that what you want? This might take several weeks, or longer.
[Even if we don't have this implemented now, it's quite reasonable that
we'd have something like this implemented in the near future.]
--
Raul
Reply to: