[aur-general] AUR 3.0.0-rc1 released

[WorMzy Tykashi]

On 1 May 2014 13:29, Dave Reisner <d at 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 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.
>

Of course not, I'm an end user. ;)

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?

>> 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.

>> 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.

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