On Thu 30 Dec 2010 03:56 +0100, Heiko Baums wrote:

Am Thu, 30 Dec 2010 04:43:46 +0200 schrieb Evangelos Foutras :

...

Personally, I don't feel strong either way. As it was explained to me on IRC, cower doesn't include any building or installation functionality, it only searches for packages, downloads them, and can also check for updates to installed, unsupported, packages.

But when I see how many times people ask for adding packages from base-devel like gcc or pkg-config to depends and how many people don't read the AUR and ABS wiki pages I'm not sure that such tools should be in the repos.

I think this is a matter for TUs and devs to discuss and decide on together. Since [community] is defacto official people may start to expect more support from the [unsupported] repo. I can imagine that TUs and devs wouldn't want this perception to prevail among users. Even if the program doesn't build or install, it still interfaces with the unsupported repo, and since it's in community, people may perceive the packages in that repo as officially supported. That's how it appears to me anyhow.

On 12/29/2010 08:56 PM, Heiko Baums wrote:

Am Thu, 30 Dec 2010 04:43:46 +0200 schrieb Evangelos Foutras:

...

Personally, I don't feel strong either way. As it was explained to me on IRC, cower doesn't include any building or installation functionality, it only searches for packages, downloads them, and can also check for updates to installed, unsupported, packages. But when I see how many times people ask for adding packages from base-devel like gcc or pkg-config to depends and how many people don't read the AUR and ABS wiki pages I'm not sure that such tools should be in the repos.

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

Oh, didn't know it use to be that way. I guess I didn't use Arch around that time or didn't know about AUR. On 12/30/2010 12:31 AM, Daenyth Blank wrote:

On Thu, Dec 30, 2010 at 01:11, Nathan Owens wrote:

...

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.

We used to have that. It was removed because people stopped using it and so almost all packages in the aur were marked "unsafe" vs "safe", so it was useless for the users.

I know what you mean. Well I would THINK that maybe it could be determined how long the user has been active though their activity of the packages and look at the quality of the packages the user has adopted/created and maybe, assuming there is a system that would monitor the out-of-date packages, if the member maintains the packages by updating them in a decent amount of time. Possibility something similar to this as to determine a regular user is trusted. On 12/30/2010 12:36 AM, Brad Fanella wrote:

On Dec 30, 2010, at 12:11 AM, Nathan Owens wrote:

...

On 12/29/2010 08:56 PM, Heiko Baums wrote:

...

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.

Wouldn't it be easier just to add more TUs than to attempt what you proposed? When would we begin to draw the line between "trusted" and "untrusted" users?

It's not a bad idea by any means. I'm just questioning the practicality of it.

Regards, Brad

Loui Chang wrote:

Please bottom post. Anyways, what you're speaking of is probably a feature that is best implemented on the client side.

You could probably hack something up that interfaces with the current AUR though. The RPC will return a list of packages by a named maintainer via msearch. See http://aur.archlinux.org/rpc.php

That's Bauerbill does with its "TrustedUsers" option. It would be much more practical though if the maintainer were included in the results of an "info" request, and maybe even whether the user is a TU.

Nathan Owens wrote:

I know what you mean. Well I would THINK that maybe it could be determined how long the user has been active though their activity of the packages and look at the quality of the packages the user has adopted/created and maybe, assuming there is a system that would monitor the out-of-date packages, if the member maintains the packages by updating them in a decent amount of time. Possibility something similar to this as to determine a regular user is trusted.

The only official distinction that we have is between TUs and non-TUs. I would support the inclusion of that data in the results from the AUR's RPC interface so that it could be more readily used by AUR helpers, but that's about it. Beyond that it is up to the users to decide whom they trust. Any system that attempts to determine a level of trust by a fixed set of metrics such as update intervals could be easily gamed, maybe even automatically with a bot. Of course, trust could be gained from regular users by a malicious maintainer via the same methods, so nothing in the AUR is ever really safe. The same could be said of TUs and [community] considering that we do not sign off packages before pushing them to the repo. It might be a bit harder to game the TU vote, but I see a vague pattern that determines acceptance that shouldn't be too hard to follow, although it would require time and wouldn't be automatable. The point is that trust is a relative term and best determined by the end user. Attempting to formalize it would likely give a false sense of security and expose casual users to greater risks.

Am Thu, 30 Dec 2010 00:11:54 -0600 schrieb Nathan Owens:

...

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 [community].

Heiko The reason I mentioned a different AUR helper is because, only assuming

On 12/30/2010 03:34 AM, Heiko Baums wrote: 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 to be.