December 2007 - Aur-dev - lists.archlinux.org

[aur-dev] [AUR2] How to go about official dependencies
by Sebastian 01 Jan '08

01 Jan '08

I'm having a problem figuring out how to cleanly handle dependencies that exist in the official repositories. I have implemented tracking dependencies that are within AUR, but since we don't have access to the main site database it's hard to manage the packages that depend on official packages. The way the current AUR handles this seems to be by simply linking to a search for that package, but that requires some messy alterations the current AUR2 database structure. It is one of the solutions, though probably a last resort. Another solution would be to have some sort of inter-process communication (XML, JSON, whatever) so that AUR2 could get some information about the official packages and store them in the database. This of course brings about redundancy and again it's quite ugly. The best solution would be to actually get access to the database and be able to easily reference those packages. If we had this access we could also work on improving and merging the code, since there is a lot of redundancy at the moment. The databases and sites could still be separate if need be, but it would be great to merge the code. I'm sure a lot of users would prefer to search packages in AUR on the main site as well, but I understand that it may look like AUR is in some way official or supported. Regardless, I'd like your opinion on how to go about this. Here's the schema for the package, category and repository relations, in case you'd like more insight into the database structure. As you will see it would be a little difficult to make a record with just the URL pointing to a search on the main site. Table "aur_package" Column | Type | Modifiers ---------------+--------------------------+----------- name | character varying(30) | not null version | character varying(20) | not null release | smallint | not null description | character varying(180) | not null url | character varying(200) | repository_id | integer | not null category_id | integer | not null deleted | boolean | not null outdated | boolean | not null added | timestamp with time zone | not null updated | timestamp with time zone | not null Table "aur_category" Column | Type | Modifiers ---------------+--------------------------+----------- id | integer | not null name | character varying(20) | not null Table "aur_repository" Column | Type | Modifiers ---------------+--------------------------+----------- id | integer | not null name | character varying(20) | not null

2 3

[aur-dev] [PATCH] Add support for variable length votes in voting application
by Callan Barrett 30 Dec '07

30 Dec '07

-- Callan 'wizzomafizzo' Barrett

2 1

[aur-dev] [AUR2] Need some feedback
by Sebastian 30 Dec '07

30 Dec '07

I'll cover a few things in this mail since I didn't want to spam the ML with 3+ threads. First off I'd like some feedback on the RPC interface. I know that AUR started work on using JSON, and in my mind it's the best contender. Django has inbuilt support for serialising to XML, JSON and YAML, so I could easily use either of those. I'm mainly interested in the user end of this - the AUR frontend (yaourt, etc.) developers. I haven't found anything to parse JSON or XML easily from bash, so I don't think it would be easy to implement either way in yaourt and other frontends. There's a Perl CPAN module[1] which may be easily used to quickly parse the data and allow the rest of the work to be done via bash, which, I guess, would be a decent compromise. In my opinion XML is just way too heavy and has too many unnecessary features for what we're going to use it for. YAML seems to be about the same, but JSON is a nice data oriented RPC that can be quickly parsed. If all goes well and we choose JSON, the interace will be compatible with AUR's, though I haven't looked int othe code much yet. On the wiki[1] someone asked to have versioned dependencies. Currently I've only implemented listing of dependencies and don't even track the version requirements. I'm not certain that this functionality is necessary at all. It has very little use, and the only use cases I can think of are validation the package, so that it's compatible with the dependencies (ie. disallowing to upload a package that depends on an older version of a package in AUR), and simply being notified that the versions don't match. Both of these, in my opinion, are pointless. As with versioned dependencies, someone asked for the ability to search for outdated packages. There are two use cases that I can think of for this. One is for a TU to find any outdated packages in Community in order to update them. I'm not exactly sure of the TU etiquette, as I'm not a TU, so I don't know if TUs update other TUs packages if they are out of date and thus this use case may not be valid. Another use case is to simply find all the outdated packages that you maintain. This is a bit pointless and probably not suitable for the search page. Any maintainer will most likely be able to quickly see any outdated packages in their Account page or by searching for packages maintained by them (since they are marked). Otherwise it could be implemented in the Account page, something like a checkbox which would toggle whether to show only out dated packages. I'm not really enthusiastic about this feature, since it is quite pointless. Another request was for regexp searching. This can probably be easily implemented since Django has this functionality built in [3]. I'm not certain that this feature would be useful. Personally I can usually (99% of the time) find the packages I want by using simple fulltext searches. I know that AUR frontends do regexp searches to be "compatible", in a way, with pacman's searching abilities. This is the only real use case I can think of. Most users of the web interface probably won't need it, and therefor it could be implemented in the RPC interface instead. Now the biggest issue I have is integrating an SCM. This should probably go in a separate thread, but I may as well discuss it here. I don't know how AUR or the main site handle it, I'd have to look into that, but I would really like to integrate an SCM backend for handling files. Initially I had the idea for the interaction to go both ways; a user could simply "git commit -a -m 'bumped version'; git push" and the everything would be updated in the database, but also for the ability to do it via the web interface like it works now. Dan pointed out that it would be hard to restrict access for the maintainers to the various repositories/modules (or however the repository would be split). The whole idea could generally raise many problems, so it may be better to go for an easier solution and have it only work one way, ie. via the web interface. It appears the TUs use CVS directly to upload packages, so they may be a but frustrated with that move. There's also the issue of which SCM to use. It seems the main site is leaning towards converting to SVN (and rsync) from CVS, but git is also a contender. Optimally only portions of the repositories could be checked out, so instead of checking out the whole repository, as it currently is with abs, you'd be able to just have the packages that you maintain. I don't know of any SCM that implements this well though. I would really love some feedback on any ways to implement this, which SCM to use, etc. But I don't want discussions to go on for ever like they are with the main site conversion. Thanks for any feedback. [1] http://search.cpan.org/~makamaka/JSON-2.02/lib/JSON.pm [2] http://wiki.archlinux.org/index.php/AUR_2#Ideas [3] http://www.djangoproject.com/documentation/db-api/#regex

2 2

[aur-dev] AUR Voting Application
by Callan Barrett 26 Dec '07

26 Dec '07

Hi there, I suppose a lot of you have seen the recent discussion about voting and quorum etc. and the way it tapered off after the discussion on IRC. Since then I've put something together as an add-on to the AUR for TUs to vote for applicants, removals and all that to help us out a little. With this set up applying to be a TU and the discussion period would still be kept on the mailing list but after that it would be taken to the AUR for the voting period. With voting like this it means it's harder to miss a vote (maybe we can even set up a notice on the front AUR page or some sort of mail notification, I dunno), voting is kept more organised, votes are far easier to check back on and your vote is kept private. So far everything is working as it should, you're able to add a new proposal to the system and once there people are able to view information about the proposal and then vote on it. It's set up in a semi-anonymous way where the fact you voted is recorded but your actual vote (yes/no/abstain) is never known. Although all the basic functionality is complete it's still missing a few things like localisation and supporting votes of a variable length but bother of these shouldn't be too hard to add. I'm interested in anyone's opinion of this and any suggestions you'd like to make for it. Some screenshots: http://img185.imageshack.us/img185/3976/closedvotelo4.png http://img184.imageshack.us/img184/1448/listviewvq9.png http://img296.imageshack.us/img296/1908/runningnotvotedkt6.png http://img183.imageshack.us/img183/9517/runningvotedab7.png http://img182.imageshack.us/img182/1553/submitfv2.png -- Callan 'wizzomafizzo' Barrett

4 6

[aur-dev] [PATCH] Updated AUR Italian translation
by Giovanni Scafora 05 Dec '07

05 Dec '07

Hi guys, here's my latest updated Italian translation. Can you apply this patch? Thanks. -- Giovanni Scafora Arch Linux Trusted User (voidnull) http://www.archlinux.org linuxmania(a)gmail.com

1 0