On Thu, May 01, 2014 at 02:04:42PM +0100, WorMzy Tykashi wrote:
On 1 May 2014 13:29, Dave Reisner <d@falconindy.com> wrote:
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.
Of course not, I'm an end user. ;)
SSDD. I fully recognize that we're extending the "attack surface" for users to do really stupid things. I think the benefits will far outweigh the negatives, and maybe there will be opportunities to automate more, reducing the reliance on human intervention for day to day operation.
This is just an example of something someone may try to do for whatever reason. It fails, and quite rightly so, you can't have two different pkgbases providing the same packages as each other. The question remains whether people should be able to alter the pkgbase of a split package. If not, that's fine. But if they are, how are they supposed to do so? Does it/should it require TU intervention?
Ask for your pkgbase to be deleted, then upload the new one. Or, play games with the package naming in the new package you upload beforehand, and have it merged. Afterwards, upload the real PKGBUILD.
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.
I understand this, and aren't trying to argue against it.
Right, this was just an extrapolation.
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.
I must have misinterpreted what you said earlier about sending the PKGBUILD with the merger request. I assumed TUs had this capability. I agree that it's not secure.
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.
I know this. I'm meaning in regards to split packages specifically.
Still doesn't make sense. The same rule applies, regardless of whether or not you split the package. d