On 4/25/07, Aaron Griffin <[EMAIL PROTECTED]> wrote: > The AUR could be made to work similar to a wiki (though more formatted > for PKGBUILDs and the like) with login required and the ability to ban > people (for completeness).
I think a wiki works in a different way, changes are (almost) always more immediate, but wathever. I can think of a lot of packages I'd like to see updated/fixed, and they could very well already be in a wikified aur. Also, an important issue in such a system is the reasons behind the changes. Most packages that require something more than the "basic" PKGBUILD.proto can be built in more than one way. How do we prevent "PKGBUILD wars" where two (or more) people keep modifying the same build just to conform it to their personal tastes? Should we limit the number of changes to a package in a given time period? And what if a package has an upstream vulnerability that prevents tha packager to update it? It's a valid reason that not everyone would know. I'm thinking about people that simply change pkgver and md5sums to get the latest version, without looking at comments and such. There could be a way to communicate to TUs, like "request to lock pkgver", that, when confirmed, refuses to modify the package if a specific pkgver is detected. Or simply a more generic "ask for TU support", with a comment box to fill with the reasons for the question. This doesn't help to alleviate TUs load, anyway. > PKGBUILDs would be run through some aur > specific pacbuild instance, which will basically just test if the > package builds or not. The package is then exposed via the web > interface, if built.... Uhm... yeah... and if someone finds a vulnerability in makepkg and breaks the server? Basically you're allowing *anything* to be executed, so I'd not trust it completely... a read-only virtual machine reloaded everytime a new package has to be built? Conclusions: it'd be really really great, but it adds a lot of new problems and layers of complexity, so TUs and devs should take some time thinking if it is convenient or not. Personally, I think it introduces more problems than it solves. bardo _______________________________________________ arch mailing list [email protected] http://archlinux.org/mailman/listinfo/arch
