[aur-general] Breaking the unspoken rule: AUR helper in [community]
ndowens.aur at gmail.com
Thu Dec 30 04:54:07 EST 2010
On 12/30/2010 03:34 AM, Heiko Baums wrote:
> Am Thu, 30 Dec 2010 00:11:54 -0600
> schrieb Nathan Owens<ndowens.aur at gmail.com>:
>> I know I am not a TU, though I figured I would put in my "two-cents".
>> I agree it may be bad for first time users to have an AUR helper if
>> they don't understand there is risks. Though this gave me a idea,
>> that may not be liked or approved of, maybe if we split AUR into
>> either packages with the most votes or maintainers that are
>> concidered trusted or been around a while, from the vice versa. Kind
>> of a trusted of the unsupported packages. Going along with the
>> assumption that the idea would work and approved of, create a AUR
>> helper, that would be in the community repo, that will only pull from
>> the trusted AUR.
> There's no need for two AURs (trusted/untrusted). That's why there are
> trusted users. And like someone said there has been a flag "save" for
> AUR packages in the past. It was removed for several reasons. It wasn't
> reliable and it was too much work for the TUs.
> And what should that have to do with the AUR wrapper? AUR wrappers which
> only use the trusted AUR can go to [community] and AUR wrapper for the
> untrusted AUR have to stay in AUR? Do I have to install two AUR
> wrappers then? And who decides which package go to the trusted and
> which to the untrusted AUR? Completely nonsense and impracticable.
> And the problem why those AUR wrappers are not moved to the repos is
> not that AUR is probably insecure. Well, that's one reason, even if I
> haven't seen one insecure package in AUR yet. The main reason is that
> people shall and must first understand how ABS and AUR are working,
> how the wrappers are working and how AUR and pacman can interact etc.
> So just keep it as it is and keep it simple. This way people have to
> install at least one AUR package (an AUR wrapper) manually.
> Btw., there is already an "AUR" for trusted packages. It's called
The reason I mentioned a different AUR helper is because, only assuming
the idea was implemented; which isn't likely, the new helper would only
pull from the trusted packages of AUR. Of course this little idea isn't
the best, it just came to mind about the idea of having a AUR helper in
community, since generally it seems that helpers are not going to be put
in community, atleast probably not yet. Though it would be nice, but
that would leave the issue of the packages the new user may get is
unsupported and not truely concidered safe, unless the end-user deems it
More information about the aur-general