[aur-general] AUR 3.0.0-rc1 released

[Dave Reisner]

On Thu, May 01, 2014 at 02:04:42PM +0100, WorMzy Tykashi wrote:
> 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. ;)

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