AUR 2

From ArchWiki

Jump to: navigation, search


Contents

[edit] Overview

Ages ago, the development of the AUR had been picked up by several individuals and the discussion on the tur-users mailing list has been revived. However, the maintainability and extendibility of the current AUR codebase is being questioned. A few people have shown interest in finally getting the 'AUR 2' project going - a total rewrite with a some important design reconsiderations, easing the addition of new features, and making the AUR code much easier to maintain.

The original AUR 2 ideas and suggestions can be found at the bottom of this page.

A live demo is available at http://aur.sebnow.info. Please test the site and try to break it as much as possible.

[edit] Update

I thought it may be a good idea to update this wiki a bit, though it doesn't seem like anyone cares. Nonetheless, we have chosen to use Django and development has progressed quite a bit. The basic functionality of the site is pretty much finished and we will hopefully be able to start working on the new and exciting features soon.

[edit] Code repositories

We have chosen to use git as the SCM for the project. You can clone the latest code from these repositories:

  • git://repo.or.cz/aur2.git - the "central" repository with the stable branch
  • git://github.com/sebnow/aur2.git - Xilon's repository - where most of the work is done
  • git://ius.student.utwente.nl/aur2 - Thralas's repository

[edit] Screenshot

Here's a screenshot of the package detail view as of 22/12/2007.

[edit] Todo

[edit] High priority

  • Support for the community repo
    • Currently only unsupported is supported (ironically). More information on how the community side of things works on the AUR is necessary. I suppose a better solution may be in order. NOTE: This might not be required at all.
    • It would be a good idea to aim for a flexible system, so that binary-based, and PKGBUILD-based, repositories can easily be added. Currently some things are hard-coded.
  • User profiles / Accounts
Last time logged (useful to drop packages from an inactive user , this feature should be just for Dev's, TU's)
  • List dependencies from the official repos
  • Permission checks when uploading packages
Only users who maintain the package or users of higher status (dev, TU) can upload packages
  • Parsing of pkgbuilds, we can no longer use bash to do it because bash sucks and is riddled with security flaws. This is really important.
    • One solution would be to create our own, minimal, bash parser using tools such as Lex/Yacc or Flex/Bison. This would probably be the best option as we have complete control over the security and features available. The obvious downsides are that the parser will probably be more buggy, less accurate, and we have to maintain it.

[edit] Medium priority

[edit] Low priority

  • Download counter
  • Think about changing the way submitting and updating packages works.
http://archlinux.org/pipermail/aur-general/2007-October/005952.html
  • Internationalisation
The code is i18n aware and mostly prepared for it, we just need a frontend interface to set the language and the actual translations. Best to leave this till the end.

[edit] Interested in helping development?

If you're interested in helping contributing to development, please add your name to the list below. Discussions are being held on aur-dev and #archlinux-aur on Freenode

  • Thralas: Fluent in PHP, yet willing to learn python and possibly ruby
  • Xilon: Fluent in PHP, familiar with Python and Django. XHTML, CSS, and even artwork!
  • Louipc: General programming/scripting knowledge. HTML, CSS, etc. If you have code I can learn it and hack it. Maybe.
  • Husio: HTML, CSS, Python, basics of coding in Django and Pylons.
  • Zio: HTML,PHP,Perl,Python,Ruby,C# I'm rewriting makepkg in Ruby for uArch.org. I can help out with testing design w/e.
  • BaSh: Fluent in PHP, HTML, CSS, yet willing to learn python and ruby.

[edit] Brainstorming

So I pose some questions to anyone who cares:

  • What works about the AUR now?
  • What doesn't work about the AUR now?
  • What kinds of things could be improved?
  • What features are missing?
  • What features are useless?

Address those questions and anything else you think is worth contributing, below. When making suggestions, make sure you keep security and practicality in mind. The AUR should not be more complex than it needs to be.

[edit] Ideas

  • The AUR should be scalable and try to remain more generic. So it should be simple enough that I could easily deploy it for internal use in my office, and robust enough to run on archlinux.org.
  • I already like the old AUR, so I'm not sure we need an AUR2, but this is ONLY because I can access it from yaourt. So if a new AUR is made I think cmd-line access should be made just as easy/easier. Other things to consider is correct transition from the old AUR keeping all users not to mention PKGBUILDS & files intact without any problems.
  • Maybe AUR2 should implement something like JSON but for bash: provide a script that fills an array with the results of a query (be it a search or package details) so it can then be sourced and ready to rock, without AWK|Sed work on the client side. Phrodo_00 19:57, 6 April 2008 (EDT)
  • The User Interface does need a bit of a polish it's a bit wonky but those small bugs should be fixed on redesign, as for the system it self, I think it's brilliant - there are some good alternatives that might also work, for example on package ownership; if a package was owned/maintained by multiple people that would be smashing, some times I come across some PKGBUILD scripts that are just inefficient and/or out of date and contacting the owner seems impossible, if the package worked like a group, the package creator, group member, TU or even the System ( if the request is not answered in a week or some odd timeout ) could approve new maintainers. Also an API might be great, that might make the whole experience better in the long run by adding people to make some apps. --thewonka 23:36, 25 December 2006 (PST)
  • The database structure allows for this but security policies and such still need implementing. - Xilon
you can actually do that in aur as well: http://aur.archlinux.org/packages.php?K=foo. uppercase param is icky though. q would be better. --huma
  • Current time out message is annoying. Time out message shouldn't disrupt your AUR browsing, searching, etc. User shouldn't be forced to press back and search again just because his session timed out.
  • things bugging me:
  1. disable browser caching, it leads to trouble when encountering the already mentioned timeout
  2. display versioned dependencies
  3. features like searching in comments and displaying the pkgs one has voted for or enabled comment notifications would be nice
  • Whenever the AUR asks the user to log in, there should be an easy way to log in and then return to that page. Often, I want to vote for a package, but I have to go back to the main page, login, and then search for the package again.
  • There should definitely be some XML-RPC interface, because now external utilities (like aurbuild, aurscripts, etc.) must parse HTML pages (which is really wrong approach).
i found this project for django framework: http://code.google.com/p/django-xmlrpc/. not sure about its state though. has anyone tried it? --huma
  • I'm looking into it. A JSON interface would probably be more suitable since XML is just too heavy weight and hard to parse. I'd imagine yaourt and similar would have to parse it manually. - Xilon
  • XML-RPC isn't the same thing as parsing normal html page. But, we can use XML-RPC, SOAP, REST or just generate specific XHTML page, that would be easy to parse. Anyway, as far as using AUR from web browser isn't so popular, it's IMO the main thing to code. Also uploading packages by done by script would be nice. --Husio 14:57, 24 January 2008 (EST)


  • There should be email notifications for package maintainers about marking their package as out-of-date and about new entry in discussion under their packages.
  • The login dialog should be in the header so you have access it whenever. I think haing it on only one page and having no easy way to get back to what you're doing is dumb. Also emphasis on the timeout page and the wonky interface like some options for packages are available on the search page while other are only in the package details. They should be available on both pages and in the same spot on both.
  • AUR2 should check if the deps of the PKGBUILD exist, something like colored link (red for non existing packages, orange for packages in unsupported and green for the official repos)
  • This is not really possible since the AUR does not have access to the main database (where the official repos are). It would be impossible determine if a package exists without this information. We would have to look at merging the databases or implementing some sort of IPC. - Xilon
  • should not allow uploading PKGBUILD without the license= tag *FIXED IN LATEST SVN*
  • It might be useful to have a votes/date chart, just to know if the package is still requested or not
  • It should use standard Atom 1.0 instead of RSS 2.0 as syndication format.
  • Add a function to search outdated packages for a specified location (as community, extra). by STiAT
  • Throw in some lint checks of PKGBUILDs. There are a lot of messy, non-standards-conforming PKGBUILDs out there, and I believe some script could be fashioned in order to check these PKGBUILDs for consistency against the PKGBUILD standards (proper variable order, proper content, etc). These checks could be made automatically upon upload, reorder the PKGBUILD and pass a small info line on the bottom 'your PKGBUILD has been rearranged. Please read <here> for info on how it should look, and <here> to see what exactly was sorted.' <- The info on what was rearranged I'm thinking something alike the w3.org validator list. Had the reordering been too much strain on the aur servers (which I doubt) the PKGBUILD could be simply rejected with a "bofh'y" info line 'this pkgbuild is wrong. fix it!'. I'd naturally opt for solution number one. by imachine
  • Various checks and possibly normalisation is planned, but rearranging variable order is not necessary imo. - Xilon
  • Also, when searching aur for packages, and having the search come up with more than one page of results, having a direct link to the result page, numbered, like 1 2 3 4 5 on the bottom instead of just 'forward' 'backward' would be great. Currently, searching for say orphaned packages and getting to packages starting with a late letter, say, 'n', even with 100 results per page, takes unnecesarily valuable time skipping through pages of no interest with the 'next' and 'previous' buttons at the bottom. by imachine
it would be also nice to add some basic regexp support. --huma
  • It should all be a WIKI.
  • Have the back-end interface with the chosen SCM directly. Comments posted by maintainers upon uploading a new package would act as the commit message. This will allow for some cool features like diffs between commits and such.
    • I think this is a great idea. Have the back-end similar to the current ABS, such that I can synchronize and diff between different versions of PKGBUILDs. For example, new versions of kernel packages tend to have major changes that affect the PKGBUILD as well as the included patches. The only way to merge these changes is through a manual diff between the PKGBUILD and all related files in the directory. A distributed SCM such as Mercurial or GIT would work well here, since AUR users tend to customize PKGBUILDs with their own patches, and a distributed SCM would lend well for each user to maintain their own "branch". --Mintcoffee 11:12, 26 June 2008 (EDT)
  • LDAP SUPPORT
  • i think we should distinguish unsupported repo from the rest of aur. its packages are not checked by tu's and may not conform to Arch Packaging Standards, which doesn't add reliability to aur as a whole. it would be a good idea to keep it away from the clean community repo. packages quality should be high on our priority list to keep a good reputation of aur and happy experience of the arch users. as a side note, i think we should implement the package verification on upload. it would ease the work of tu's and keep us from broken or bogus packages. --huma
  • Show number of downloads. --UnbreakableMJ 06:31, 9 October 2007 (EDT)
  • Git, Mercirial, Bazaar suport to control your PKGBUILDs. It's not easy to manage PKGBUILDs. Little change, then you have to pack it and send to AUR. It would be nice, if I can just send my (git, mercurial or bazaar) repo to AUR, and script will get the last change and make update on server. It doesn't have to use (git, mercurial, bazaar) as version control system, and store all those files. --Husio 03:10, 29 May 2008 (EDT)
Retrieved from "http://wiki.archlinux.org/index.php/AUR_2"
Personal tools