Migrate AUR towards public subversion repository?

Spider.007 · 2008-08-02 11:33:26

The following idea has been in my head for some time; I was going to just build it; but I figured some discussion might be useful

I think the current setup of the AUR doesn't provide the tools for people to maintain a package. I frequently find myself wanting to add something without wanting to maintain it; or wanting to make a minor fix to an existing entry in the AUR. I know the first problem might be solved by disowning the package, but I have an alternative solution I would like your opinion on.

How about changing the AUR so it would be a web-interface to a subversion repository where everyone can change files in a wiki-like way? This would just be a light webinterface with a simple text-editor area, and some file management tools. The current user-database would be used to verify users, and there would be a single application-account in the svn repository. The application would maintain the relation between commits and users; thereby providing blame functionality to each file. The biggest difference would be that everyone could update every file; with the application providing a complete log of what was changed by who. For external applications to integrate with the AUR, the svn repository could be public read-only.

What do you think about this setup; feedback is welcome

Allan · 2008-08-02 12:36:43

Interesting idea. I'd almost prefer wiki style than svn as I think that would be more accessible to everyone.

I think there is still the need for a master PKGBUILD that is only editable by the maintainer. Then there could be a version editable by everyone to suggest improvements.

Spider.007 · 2008-08-02 15:26:29

Making a package only editable for the maintainer should be a simple flag; but why would you want that?

I think that using an actual wiki might cause various problems with external applications because a web-application as primary storage might not be the best idea. Subversion seems more logical to me because the AUR might then exist in ABS as well. It might also provide an alternative way of updating the packages; using a svn-auth wrapper that uses a custom user-database.

rooloo · 2008-08-02 15:40:18

if the PKGBUILDS are accessible by anyone, then anything can be done with them. As it is now, the voting system in place in the AUR helps new comers to arch see what packages are good and which ones may not be as good. If PKGBUILDS are public, then things like the voting system become useless, because at any time the package could be ruined by anyone. Cleaning up after this sort of mess could be a waste of time and resources.

Arch phylosophy is KISS - I do not think adding in svn public access adds to that simplicty. JMO

I think there has to be some way of doing it like git, being able to have multiple branches of the same project. This way one could easily merge updates into the master private branch.

Dusty · 2008-08-02 15:51:07

More important than voting, the 'safe' flag would not apply to packages that have been edited by 'just anyone'.

I think a happy medium would be to have a 'master' PKGBUILD that the maintainer and TU's can kind of guarantee, plus the ability for other users to supply a series of 'revised' PKGBUILDs that people would NOT trust unless they knew what the revisions did (or they trusted the person who posted them).

Dusty

dolby · 2008-08-02 15:54:50

I dont care what the AUR looks like or uses but i would prefer uploaded PKGBUILDs reviewed by TUs before uploaded & are accessible by users.

eg. http://slackbuilds.org/repository/12.1/graphics/scrot/

Last edited by dolby (2008-08-02 15:56:44)

Allan · 2008-08-02 16:01:08

Note that the TUs don't mark packages as safe anymore as that feature has been removed from the AUR. We just don't have the manpower for that. So you should always, always, always look at PKGBUILDs before you use them. If anything looks strange or your are not sure about something then ask. Also, voting is not about package quality, is is about wanting it to be included in the [community] repo.

I guess the reason I like having a master PKGBUILD that only the maintainer can modify is so people can show their ability to create good PKGBUILDs and eventually become TUs. It also prevents abuse by malicious parties.

rooloo · 2008-08-02 16:26:30

is is about wanting it to be included in the [community] repo

Isn't that the whole idea of community supported and unsupported? I'd say that adds highly to the quality of the package if it makes to community repository.

Spider.007 · 2008-08-02 16:55:22

rooloo wrote:

I think there has to be some way of doing it like git, being able to have multiple branches of the same project. This way one could easily merge updates into the master private branch.

I was hoping that my suggestion of using subversion would not emerge into a cvs <> svn <> git discussion. What I mean is a versioned file repository and I couldn't care less about the actual implementation

dolby wrote:

I dont care what the AUR looks like or uses but i would prefer uploaded PKGBUILDs reviewed by TUs before uploaded & are accessible by users.
eg. http://slackbuilds.org/repository/12.1/graphics/scrot/

Yep, so would I. But what does that have to do with the idea I posted?

Allan wrote:

[...]
I guess the reason I like having a master PKGBUILD that only the maintainer can modify is so people can show their ability to create good PKGBUILDs and eventually become TUs.

Okay; but wouldn't that be just as visible by the changes they commit, as it would be by the number of packages they add?

Allan wrote:

It also prevents abuse by malicious parties.

It does, but only a little bit since those parties could upload malicious PKGBUILDS just as well as they could edit existing ones. When locking of packages would be supported; it might defeat the whole idea of packages being publicly maintained.

DonVla · 2008-08-02 18:18:07

i would change the whole voting system. there should be two kinds of votes:
1. good PKGBUILD
2. bad or malicious PKGBUILD

then if there are more then - let's say - 5-10 votes of the second kind then a TU should be notified. this also implies a popularity contest for community inclusion.

btw: i would like to have at least a delete request button. there are some packages which are obviously deprecated (like tcgui which i abandoned).
since arch is a rolling distro there is no need to keep them in AUR.

ps: i would also "automate" the AUR system, i.e. a user _has_ to check every 3months if his packages are up-to-date and tag them checked, if not the user gets a notification. if he does not respond then the package gets orphaned.

Last edited by DonVla (2008-08-02 18:48:51)

mastercpp · 2008-08-02 20:21:18

I don't like the idea, that anyone could edit every PKGBUILD in one big repository. Maybe it would be better to give every registered user his/her own little repository.
And we probably should use git instead of subversion, because it's easier to use, requires only a HTTP server and is just better

DonVla wrote:

btw: i would like to have at least a delete request button. there are some packages which are obviously deprecated (like tcgui which i abandoned). since arch is a rolling distro there is no need to keep them in AUR.

I also thought about this. I think this is a good idea.

Jessehk · 2008-08-02 20:48:01

DonVla wrote:

i would change the whole voting system. there should be two kinds of votes:
1. good PKGBUILD
2. bad or malicious PKGBUILD
then if there are more then - let's say - 5-10 votes of the second kind then a TU should be notified. this also implies a popularity contest for community inclusion.
btw: i would like to have at least a delete request button. there are some packages which are obviously deprecated (like tcgui which i abandoned).
since arch is a rolling distro there is no need to keep them in AUR.
ps: i would also "automate" the AUR system, i.e. a user _has_ to check every 3months if his packages are up-to-date and tag them checked, if not the user gets a notification. if he does not respond then the package gets orphaned.

I like those suggestions.

Allan · 2008-08-03 01:32:54

DonVla wrote:

i would change the whole voting system. there should be two kinds of votes:
1. good PKGBUILD
2. bad or malicious PKGBUILD
then if there are more then - let's say - 5-10 votes of the second kind then a TU should be notified. this also implies a popularity contest for community inclusion.

1 malicious vote should be enough for a TU to look at it. If you every find a PKGBUILD that is malicious send an email with the package to aur-general straight away.

DonVla wrote:

btw: i would like to have at least a delete request button. there are some packages which are obviously deprecated (like tcgui which i abandoned).
since arch is a rolling distro there is no need to keep them in AUR.

If that package can still be updated to the latest version, then the PKGBUILD is still useful and could save someone else a bit of time.

Dieter@be · 2008-12-01 09:30:27

I like the idea of keeping one maintainer who maintains the actual pkgbuild, while users can submit proposals/enhancements etc easily viewable in a category "enhancement requests" or something.
the maintainer can then decide to import the contribution from a user. (backend-wise, this is very similar to how github works, their code is fully open source. maybe that can help)

If you want to use a wiki, go ahead, but it should not replace version control imho

You could also take another view on this: keep the aur as the "interface that lists the resulting packages" and keep the generation/creation of those packages/pkgbuild somewhere else. For example: it could be as easy as having each maintainer supplying (in his AUR settings) the address of a github url that is a git repo hosting the packages. For each of his packages, you can then provide a link called "package source" pointing to the github page. If a user goes there, he can see the git repo, see if it's forked by other people (although it would be a bit harder to see the different variations of a pkgbuild around like this i think), fork it himself, etc.

MindTooth · 2008-12-01 11:14:15

Maybe using git would make this easier to achive.

Birger

LTSmash · 2008-12-06 02:19:29

Jessehk wrote:

DonVla wrote:
i would change the whole voting system. there should be two kinds of votes:
1. good PKGBUILD
2. bad or malicious PKGBUILD
then if there are more then - let's say - 5-10 votes of the second kind then a TU should be notified. this also implies a popularity contest for community inclusion.
btw: i would like to have at least a delete request button. there are some packages which are obviously deprecated (like tcgui which i abandoned).
since arch is a rolling distro there is no need to keep them in AUR.
ps: i would also "automate" the AUR system, i.e. a user _has_ to check every 3months if his packages are up-to-date and tag them checked, if not the user gets a notification. if he does not respond then the package gets orphaned.
I like those suggestions.

+1

1 malicious vote should be enough for a TU to look at it. If you every find a PKGBUILD that is malicious send an email with the package to aur-general straight away.

+1

If that package can still be updated to the latest version, then the PKGBUILD is still useful and could save someone else a bit of time.

What if it simply abandoned? Then the PKGBUILD would do no good... guess there's should be a button that asks TU's to check if the package is really desprecated and the PKGBUILD cannot be reused...

Arch Linux

#1 2008-08-02 11:33:26

Migrate AUR towards public subversion repository?

#2 2008-08-02 12:36:43

Re: Migrate AUR towards public subversion repository?

#3 2008-08-02 15:26:29

Re: Migrate AUR towards public subversion repository?

#4 2008-08-02 15:40:18

Re: Migrate AUR towards public subversion repository?

#5 2008-08-02 15:51:07

Re: Migrate AUR towards public subversion repository?

#6 2008-08-02 15:54:50

Re: Migrate AUR towards public subversion repository?

#7 2008-08-02 16:01:08

Re: Migrate AUR towards public subversion repository?

#8 2008-08-02 16:26:30

Re: Migrate AUR towards public subversion repository?

#9 2008-08-02 16:55:22

Re: Migrate AUR towards public subversion repository?

#10 2008-08-02 18:18:07

Re: Migrate AUR towards public subversion repository?

#11 2008-08-02 20:21:18

Re: Migrate AUR towards public subversion repository?

#12 2008-08-02 20:48:01

Re: Migrate AUR towards public subversion repository?

#13 2008-08-03 01:32:54

Re: Migrate AUR towards public subversion repository?

#14 2008-12-01 09:30:27

Re: Migrate AUR towards public subversion repository?

#15 2008-12-01 11:14:15

Re: Migrate AUR towards public subversion repository?

#16 2008-12-06 02:19:29

Re: Migrate AUR towards public subversion repository?

Board footer