[aur-general] Tarball Guidelines

[Dave Reisner]

On Mon, Dec 06, 2010 at 03:20:06PM +0100, Heiko Baums wrote:
> In most cases there's a reason for having binaries, icons and the like
> in a package. And whether such a package actually has a bad quality or
> its contents are necessary can't be decided by a bot.

In _all_ cases, binaries are not permissable as stated by the AUR
guidelines [1]. Your opinion doesn't change this. A proposal to amend the
guidelines can.

> 
> <snip>
> 
> 
> Btw., the QA in AUR is usually pretty good, because comments for a
> package are usually written pretty fast by other users or TUs if a
> package doesn't respect some guidelines, has bugs or a bad quality or
> isn't trustworthy.

My day job is QA. I assure you, based on what Kyle found and in my own
personal experience, it's not that good. A lot of things do get caught.
A lot of things don't. How many packages still don't have an arch=
declaration, or still make reference to $startdir? While less offensive,
I could give you a list of packages that have 2777 permissions on the
tarballed folder. Kyle hasn't even touched parsing the PKGBUILD itself,
but I might be tempted to borrow his database and do such a thing.

> 
> And if a maintainer doesn't respond to such comments or doesn't fix
> those issues users usually send an orphan request to the mailing list to
> be able to fix these issues themselves.
> 
> So there's usually no need for such a bot.
> 
> > I've also come across a bug in the AUR.  In short, the tarball URL
> > provided by the RPC interface is different from the tarball taken from
> > the html page.  The RPC tarball is *exactly* what was uploaded.  While
> > the html tarball has been sanitized.  So let's say someone uploads
> > something that is not even a tarball.  The AUR fixes this and pushed
> > it to the html.  The RPC link goes to the original, and Mr Robot
> > complains.  Human looks at html tarball and sees nothing wrong.
> > Confusion abound.  I'll remove those comments.
> 
> I don't know how all the AUR scripts like yaourt, aurbuild, clyde etc.
> retrieve the tarballs from AUR, whether they get it from the HTML or the
> RPC interface. And I don't know how the HTML interface should sanitize
> packages and what you actually mean with sanitize. But I had absolutely
> no such problems with AUR packages, yet.

As an author of one of these abominations, I (cower) make an assumption
that the package can be found at /packages/%s/%s.tar.gz, simply because
the URLPath provided in the JSON reply is not trustworthy. It seems as
though the database is populated on upload, rather than after parsing,
which leads to these problems. It's not really a big deal. Frankly, if
any change were to be made, I'd vote for URLPath to be removed from the
JSON reply.

dave

[1] https://wiki.archlinux.org/index.php/AUR