On Thu, May 01, 2014 at 01:04:07PM +0100, WorMzy Tykashi wrote:
On 1 May 2014 02:30, Doug Newgard <scimmia@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