January 2008 - Aur-dev - lists.archlinux.org

[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