Re: broken .orig.tar.gz (Re: package upload rejected - no email)
Clint Adams <firstname.lastname@example.org> writes:
> On Mon, Mar 17, 2008 at 04:27:03PM -0700, Russ Allbery wrote:
>> Joerg has been moving towards doing more of this, and I applaud him for
>> doing so. I hope that anyone else who works on NEW does the same.
>> It's one of our best opportunities to raise the general quality of the
>> archive up-front, rather than filing bugs and trying to chase down
>> maintainers who sometimes no longer care now that their software is in
>> the archive.
> I disagree with this entirely. The critical part of NEW checking is the
> license: whether it's legal to distribute and whether it's suitable for
> main. Anything else can be fixed up after the fact, and discretion
> beyond that should be discouraged, in my opinion.
> Furthermore, since anything (including the license) can be broken in
> subsequent uploads, making the NEW checkpoint more meaningful could lull
> one into a false sense of security.
The last part is certainly true, although I don't think that makes the
check at that point unuseful. The initial upload is the point at which
it's the most likely that significant misunderstandings or structural
flaws will show up. For example, someone who doesn't realize they
shouldn't repackage upstream without a good reason will tend to do it
every time, and hence it will show up in the initial upload. The bugs
introduced later tend to be (although aren't always) less rooted in basic
This same argument applies to licenses, for what it's worth. New upstream
source releases can and do introduce licensing problems, but enough of the
license problems show up in the initial upload that NEW is still
As for having this be outside the scope of NEW and something we can check
later, I agree in principle, but in practice packages are rarely ever
looked at again in a comprehensive way after NEW except via automated
checks. I'm painfully aware of just how limited Lintian is. There are a
lot of problems that it just isn't in a position to notice. If we had a
regular practice of more detailed package audits of existing packages,
that would be great, but that generally doesn't happen until packages
change maintainers. In the meantime, NEW is structurally our best shot at
I'd love to see a better approach to the underlying problem, though.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>