[aur-general] AUR 3.0.0-rc1 released

[Dave Reisner]

On Thu, May 01, 2014 at 01:04:07PM +0100, WorMzy Tykashi wrote:
> On 1 May 2014 02:30, Doug Newgard <scimmia at archlinux.info> wrote:
> >
> >
> > Yep, that was the concern exactly. Nothing insurmountable, just wanting to
> > clarify how it works upfront.
> 
> I share this concern. I've just uploaded slim-git [1] to the aur-dev:
> 
>   pkgbase=slim-git
>   pkgname=('slim-git' 'slimlock-git')
> 
> If I now wanted to change the pkgbase to something more encompassing, e.g.
> 
>   pkgbase=slim-git_slimlock-git
> 

I don't get it. pkgbase is intended to be no different from what it is
in the binary repositories, e.g.:

linux -> linux linux-headers linux-docs
pacman -> pacman pacman-contrib

What you're proposing here makes no sense.

> I get the following error when I try to upload the aurball
> 
>   "You are not allowed to overwrite the slim-git package."
> 
> I assume this is because my updated PKGBUILD provides slim-git (and
> slimlock-git), but is in essence a completely different package,
> because of the different pkgbase value. In this situation, I cannot
> upload the PKGBUILD and have the old one merged into it, due to the
> conflict.

And if you think about it, this makes sense. If pkgbase 'a' and 'b' both
provide 'libfoo', then what does the URI fragment '/packages/libfoo'
point to? The basic unit of upload and download has essentially changed
to 'pkgbase' rather than 'pkgname', but there's still a uniqueness
constraint between package names.

> As I understand it, my options are to either upload the new PKGBUILD
> with different/temporary pkgnames, request to have the packages
> merged, then undo the rename and upload the updated PKGBUILD again,
> with the original pkgnames.
> 
> The other option, as Dave has suggested, is to submit the updated
> PKGBUILD along with the merge request. Is this ideal, or would a patch
> that can be applied directly onto the existing PKGBUILD be a better
> idea? (or in this case, where a patch would be overkill, is it
> preferable to just ask a TU to make the changes directly to the
> PKGBUILD?)

Allowing anyone to edit PKGBUILDs and tarballs on the webserving side as
a matter of procedure should never happen. This isn't secure at all.

> Or alternatively, should pkgbase changes be disallowed completely,
> except where it's really necessary?

Not sure what this accomplishes. If there's no pkgbase, it's just
assumed to be whatever ${pkgname[0]} expands to. This is a carryover
from makepkg.

> Cheers,
> 
> 
> WorMzy
> 
> [1] https://aur-dev.archlinux.org/pkgbase/slim-git/