Re: broken .orig.tar.gz (Re: package upload rejected - no email)
On Mon, Mar 17, 2008 at 05:18:20PM -0700, Russ Allbery wrote:
> 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
> misunderstandings.
The check is probably not unuseful. Instead of a report or a series of
bugs, however, the result of that check is sometimes a REJECT and
thus a need to re-upload to NEW.
> 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
> this.
I'm not convinced that the majority of these uncaught problems are
significant enough to worry about. I would be surprised, for example,
if using a non-pristine tarball was ever regarded as a release-critical
issue.
Why slow down NEW processing to check things like that?
Reply to: