On 6/1/05, Dusty Phillips wrote:

Since AUR can contain unofficial PKGBUILDs, I question the utility of this? Why don't users with binary package dbs submit the packages to AUR instead.

The answer, of course, will be "because they have to build the packages themselves". To this end, I think a script based on sourcepac that automatically downloads PKGBUILDs and builds them would be more useful.

This was discussed a while back - and the answer is the same old "security". The AUR has no validation for PKGBUILDs... I could submit a PKGBUILD that has an install file that runs "rm -rf /" and the AUR will handle it just fine... an automated command to download a PKGBUILD from the AUR, and makepkg it without any checking, I can wipe your harddrive when you try to install madwifi from AUR

I should mention (in other forums too, probably, but you brought up the issue so you get the benefit of my spontaneous response!) is that I have been thinking about the possible merits of allowing multiple versions of the same package for some time in AUR. It's an idea that appeals to me greatly. I think the challenge will be making it simple enough to handle multiple versions of a package without it becoming overly complex. We Arch-ers like our simplicity! I'd be interested to hear more ideas about how an elegant system could be constructed that would allow multiple versions of the same package by different maintainers. What would the db look like? What would the UI look like? What would the PKGBUILD hierarchy look like? How would things get handled when you transition unsupported->community, etc? How would we explain it simply to the community? Of course, there's a lot of AUR discussion to be done. It's nearly time to sit down and have a broad-based community discussion about it and think about what's next. I'm sorry I've had so little time to devote to it recently. I'm planning to sit down with my calendar very soon to figure out some dates to propose for the Grand Unified Discussion Session. ;) - P cactus wrote:

To me, the main reason for the continued existence of personal repositories, is that the aur only allows a single package per name. If two people want to package the same utility differently, too bad. Only one person can "own" it in the aur.

Further, I custom compile several binaries (php with tidy-2.0 support for instance). If someone else wants to use my binary, then they are free to do so, instead of compiling it themselves.

Those are just two examples off the top of my head, why I think personal user repositories will never go away.

In all honesty, I am going to use mBira as a front end to my personal binary repository (replacing my previous use of PRIMAL). If nobody else does, then that is their choice, and they are welcome to make it.

I just figured I would let people know about it, and let them make their own choices.

On 6/1/05, Dusty Phillips wrote:

...

Since AUR can contain unofficial PKGBUILDs, I question the utility of this? Why don't users with binary package dbs submit the packages to AUR instead.

The answer, of course, will be "because they have to build the packages themselves". To this end, I think a script based on sourcepac that automatically downloads PKGBUILDs and builds them would be more useful.

This was discussed a while back - and the answer is the same old "security".

The AUR has no validation for PKGBUILDs... I could submit a PKGBUILD that has an install file that runs "rm -rf /" and the AUR will handle it just fine... an automated command to download a PKGBUILD from the AUR, and makepkg it without any checking, I can wipe your harddrive when you try to install madwifi from AUR

True that AUR doesn't verify PKGBUILDs, but at least I can look at the PKGBUILD online and decide on what it contains. A user repository sends binary packages; it could contain a package that rm -rf / in the post-install and I wouldn't even have had a chance to look before the damage was done! cactus: I didn't mean to attack personal repositories; in the case of you and phrakture, I've used both in the past and may continue to. But I don't trust anybody else to build a package properly, even if they don't mean to harm it. For me, I'd like to see all PKGBUILDs in AUR. Then I'd like to be able to view the PKGBUILD to verify the integrity (already easily done online), and then be able to run a simple program that will automatically install from AUR without me having to manually download the pkg and makepkg it... If the pkg is in somebody's repo, I have to edit pacman.conf, and personally, I like to keep that as simple as possible... I hate adding repositiories so I can download just one or two programs from them. But that might just be me. I'm remembering days when I had a loooooooooooong list of apt-get sources that took literally an hour to update on dialup... lovely thing about arch is I don't even remember the file that apt-get sources are stored in! :-) Anyway, I hijacked your topic here... I recall phrakture had a script to grab PKGBUILDs from AUR, so it shouldn't be hard for me to extend this to automatically build too. Dusty

On Wed, Jun 01, 2005 at 02:29:37PM -0500, Aaron Griffin wrote:

On 6/1/05, Dusty Phillips wrote:

...

Since AUR can contain unofficial PKGBUILDs, I question the utility of this? Why don't users with binary package dbs submit the packages to AUR instead.

The answer, of course, will be "because they have to build the packages themselves". To this end, I think a script based on sourcepac that automatically downloads PKGBUILDs and builds them would be more useful.

This was discussed a while back - and the answer is the same old "security".

The AUR has no validation for PKGBUILDs... I could submit a PKGBUILD that has an install file that runs "rm -rf /" and the AUR will handle it just fine... an automated command to download a PKGBUILD from the AUR, and makepkg it without any checking, I can wipe your harddrive when you try to install madwifi from AUR

There's a subtlety here that I think you've missed. The AUR can have contributions from anyone, with very weak-grained (opposite of fine-grained) control over who's packages you see. Essentially it'd be one huge personal repo that anyone could submit to. You have to trust everyone in existence if you trusted a random package from AUR. A personal repo is usually run by a single person. It's fairly easy to say if you trust that one person's packages or not. By using a personal repo, I'm implicitly trusting the maintainer of that repo. By using a automatic-package-installing AUR, I'm implicitly trusting anyone with enough brains to create an AUR account. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.

On Wed, Jun 01, 2005 at 08:20:57PM -0600, Dusty Phillips wrote:

...

A personal repo is usually run by a single person. It's fairly easy to say if you trust that one person's packages or not.

By using a personal repo, I'm implicitly trusting the maintainer of that repo. By using a automatic-package-installing AUR, I'm implicitly trusting anyone with enough brains to create an AUR account.

Yes, but using a semi-automatic package-installing AUR allows me to install from the PKGBUILD after I've reviewed it for saneness. The thing I don't like about binary repos is having to maintain them all in pacman.conf... when it gets down to one repo per package, that sucks.

Dusty

Right, but I wasn't talking to you... or about that. I was responding about the "security" answer... Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.