[aur-general] AUR helpers and AUR standards

Oon-Ee Ng ngoonee.talk at gmail.com
Fri Mar 2 02:23:16 EST 2012


On Fri, Mar 2, 2012 at 8:33 AM, Heiko Baums <lists at baums-on-web.de> wrote:
> Am Fri, 2 Mar 2012 07:45:34 +0800
> schrieb Oon-Ee Ng <ngoonee.talk at gmail.com>:
>
>> Splitting off from the TU application thread that's becoming more of a
>> discussion on the above:-
>>
>> My (user) perspective - when did being able/not to install packages
>> from a helper (for example yaourt) become a benchmark for deciding how
>> 'correct' a PKGBUILD is?
>
> It's not only the helper, but it's one point. And it was not only the
> split package but also those two depends arrays in some PKGBUILDs.
>
> A correct PKGBUILD should in my opinion respect the official packaging
> standards. And since AUR doesn't support split packages it's just not
> officially supported.

As I understand it the reason the AUR doesn't support split packages
is more along the lines of "hard to implement" and/or "noone has
bothered to add it" rather than "the AUR shall not have split
packages". If a workaround allows split packages to work fine without
having to rewrite the AUR, that's a GOOD thing to me. Note: 'work'
means with makepkg.
>
> And why can't a package being built in a way that it can easily
> installed by those helpers?
>
Helpers are only helpers. Nothing wrong with using them, but they're:-
a) not official
b) not a suitable substitute for knowing how to download a tarball and
run makepkg

If a user can't do b) AUR helpers do them a dis-service, IMO. Better
to learn what's going on behind the scenes.

I've used yaourt and bauerbill before, and they DO make things easier,
but if we ever reach the point that a large group of users only know
how to use the AUR through helpers Arch would be a very different (and
worse) place.


More information about the aur-general mailing list