[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Why slow down NEW processing to check things like that?

Reply to: