- Aur-dev - lists.archlinux.org

[aur-dev] AUR2 directory structure
by Sebastian Nowicki 07 Jan '08

07 Jan '08

I'd like to implement saving files to disk, but to do so I first need to decide on the directory structure. Django's FileField model field wants to upload files relative to MEDIA_ROOT[1]. Since I'm currently using the main site's CSS and images directly, MEDIA_ROOT hasn't been used yet. To simplify the problem I think it's best to simply ignore the fact that there may be an SCM backend. We should just focus on the relative directory structure. The easy way to go would be dumping everything into MEDIA_ROOT/repository/package_name/ (possible using MEDIA_ROOT/packages/...). It's simple and easy to navigate. The directory would hold the PKGBUILD, and source or install files and the tarball. The files would be accessible via MEDIA_URL/[packages/]repository/package_name/, with packages/ being optional. I'm not sure that using MEDIA_ROOT is a good idea since, if we eventually get some, images and CSS files, etc. would also go into it, so it seems a bit odd. Also if we do choose to go with an SCM like subversion then it would most likely have to be separated from the MEDIA_ROOT. I'm not sure if overloading this behaviour of the FileField is possible, so we may simply need to use a CharField and do anything, that FileField does for us, manually. For those familiar with the current AUR code, how does AUR do it? Does it even store the source file separately? And how does the main site handle it? [1] http://www.djangoproject.com/documentation/model-api/#filefield

1 1

[aur-dev] [PATCH] Add notify column in search results and notify button
by Callan Barrett 07 Jan '08

07 Jan '08

Lets you toggle notification for many packages at once and tells of their status from the search results (like the voted column). Works for me. -- Callan 'wizzomafizzo' Barrett

1 0

[aur-dev] AUR Variable Names
by Callan Barrett 06 Jan '08

06 Jan '08

I'd like some suggestions on how we deal with the issue of this: http://aur.archlinux.org/packages.php?do_Details=1&ID=6978&O=0&L=&C=&K=&SB=… I've seen suggestions of mod_rewrite but really nothing further, I'll start us off but I really want opinions from at least a few different people. To begin I'm not really thrilled with the idea of mod_rewrite at all and I can't find much of a point to using it, I've been told it will be amazing because then we can have urls like /search/foo/ but so what? People don't search using urls they search with the search form and the fact we can start going /package/1337/ instead of say packages.php?id=1337 is so incredibly minor why should we bother? I propose that at the very least (that is even if we decide to use mod_rewrite for some crazy reason) we change the variable names to something that's actually descriptive and try get rid of as many variables as possible. If you take a look at tardo's repo you can see the details page now only requires the package id variable and nothing else which is a great step in the right direction, we can also get rid of the sorting options in the search form because you can already sort via the links in column names and the variables do_Search is just as pointless as do_Details. With just these changes we get something like O=0&L=&C=&K=&PP=&SeB= which we could probably make even smaller and nicer if we changed variable names to be descriptive. Anyway, most of all I want to hear what other people have to say about this because I think choosing the right names and issues like backwards compatibility are pretty important. -- Callan 'wizzomafizzo' Barrett

5 7

[aur-dev] Roadmap
by Simo Leone 04 Jan '08

04 Jan '08

Hey guys, I would have written this email earlier, but I'm currently overseas enjoying the effects of global warming (since when does it not snow in the arctic?). I had a few spare minutes and decided it might be a good time to sit down and finally write the damn thing. Right, so I just wanted to get a few things cleared up about where I want to take the AUR, short and long term. In the short term, I'd like to keep things realistic. What can and can't we do with the current level of interest in the AUR? Big sweeping changes are out of the question, the userbase is quite large and the AUR is something very prominent in Archland. I haven't read an Arch review that doesn't mention the AUR in quite a while, so we must've got something right. We should be somewhat cautious about large public-facing changes and introducing regressions. Short term fast-track changes should be things like bugfixes, and admin-side changes, and small no-brainer type stuff. Keeping with that, I'd like to tweak the interface a bit. It's always struck me as a tad clunky, and could use some refinement. Parts of it are buggy too. Another small welcome change would be fixing those nasty URLs. Changes here should be backward-compatible, since AUR links are likely pasted in all sorts of places. The AUR's long-term future is less certain. One thing I'd like to get cleared up is this stuff about AUR2. First off, I'd like to know how many separate people/groups are currently coding some AUR-successor. I admit that I probably made a mistake in even introducing the idea of recoding the AUR, and after some further thought it's probably in our best interests to improve upon what we have, and be satisfied with it before any kind of recode is seriously considered. If you're currently working on a 'new' AUR, now's a good time to speak up, so your hard work doesn't go to waste. That said, I've always felt that the AUR's codebase is on a pretty shaky foundation, and needs some serious rearranging. One of my biggest long-term goals is to functionalize the code, and separate the HTML from underlying logic, particularly SQL queries! As it stands, most of it looks like HTML/SQL/PHP soup, a lot of it quite repetative. This is really bad programming practice for a whole shizload of reasons, security among them. Another long-term issue is cleaning up the data. A lot of the users are dead, and packages uncared for. The idea of package maintenence/ownership might be interesting to reexamine and rethink at some point, the results might really benefit the community. There is a whole whole lot more that belongs on both lists, but taking it slow, steady, and simple, is best. The AUR is still growing and maturing as a project, let's not try to make it grow up overnight. Lastly, I welcome you to send patches and take advantage of aur-dev. Developing is always more rewarding when you have others to put their momentum in the same direction. -- Simo Leone Arch Linux Developer

8 7

[aur-dev] [PATCH] Removes timeout page and moves login form to header
by Callan Barrett 04 Jan '08

04 Jan '08

This removes the need for a timeout page (and probably hacker.php) and moves the login form and status to the header. If your login times out you won't lose your place anymore and links will always work. Works for me but at the moment index_po.php is imported in aur.inc which has to stay until the translations from it for login are moved to aur_po.php. -- Callan 'wizzomafizzo' Barrett

4 6

[aur-dev] [PATCH] Fix bug with botched AURSID values
by Callan Barrett 03 Jan '08

03 Jan '08

In the check_sid function in aur.inc the condition for expiring the cookie and redirecting to hacker.php could never be met and instead the user would be given blank login instead of being considered logged out, now fixed. This also means we no longer need either hacker.php or timeout.php at all. Also, this bug seems to be present in the AUR version running on aur.archlinux.org. -- Callan 'wizzomafizzo' Barrett

1 0

[aur-dev] [PATCH] Adds support for TUs and devs to disown packages they do not own
by Callan Barrett 02 Jan '08

02 Jan '08

This is to add support for either devs or TUs to disown packages whether they own them or not. I know of countless times where I or another TU have been asked to orphan packages for someone and end up having to adopt the package first and then disown it, this gets really tedious for more than one package. As far as I can tell there's no other way to disown packages you don't own and if there is at least this is a more obvious way, pretty sure I didn't leave anything out in the patch. -- Callan 'wizzomafizzo' Barrett

1 0

[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