From 58de6280fdadd29fba1c550a25de714c1d543c61 Mon Sep 17 00:00:00 2001 From: canyonknight Date: Wed, 23 May 2012 13:17:04 -0400 Subject: Update AUR README Old README file is severely outdated, update with current information. Signed-off-by: canyonknight Signed-off-by: Lukas Fleischer --- README | 174 +++++++++++++++++++++++++---------------------------------------- 1 file changed, 67 insertions(+), 107 deletions(-) diff --git a/README b/README index 12f64c77..805e0cec 100644 --- a/README +++ b/README @@ -1,107 +1,67 @@ -This is the finalized draft of the project requirements for the -new Arch package submittal process. AUR (Arch User-community Repo). -The sub-directories contain more specific implementation notes -for each component of the project. - - -Requirements: -------------- -1) User accounts (users, TUs) - - Create account. (email address required) - - Update account (change password/email address) - - Log in/out - -2) Search for packages (public) - - needs knowledge of ALL pkgs (OfficalRepos/AUR/Unsupported). This - should be easy enough if this site lives on the same machine as - the current package database (dragon?), or is allowed to query - the db. - - Display official repo (current/extra) a package lives in. - -3) Manual voting (requires user acct) - - reset/clear all votes (for starting over, this can be added later - if there is any demand for it) - -4) Package Management - - A package can be submitted by anyone (as long as they create - an account with a valid email address on the web site). From - there, a TU inspects the package and works with the submitter - to resolve any bugs/issues. Once approved, the TU can place the - package in the AUR. From there, if the package is popular enough - (or deemed necessary), a developer can move the package from the - AUR to extra/current/etc. A developer can also downgrade a - package from extra/current/etc to the AUR. - - The person that uploaded the new package can make changes to - it before it has been added to the AUR. - - TUs need to be able to purge packages in "Unsupported" if the - package is no longer maintained and there is no interest in - keeping it. - - Packages in the AUR/Unsupported need some sort of 'flag out of - date' support. - - Interested users can download the package from "Unsupported" - and build/install it by hand. - - Provide a separate installation of flyspray for tracking bugs - for packages living in the AUR. All bugs should be resolved - in either flyspray (AUR/official) prior to a package being - promoted/demoted. - -5) Reports - - package popularity by number of votes - -6) Wiki Docs (UID/GID db, provides db, irc nicks/names TUs/devs) - - Move the appropriate dev wiki pages to the new system's - wiki area. The devs will just need to consult the UID/GID - list from the new system site rather than our own wiki. - -7) Submitting 'new' packages by users. Initially start with - a simple web upload page where users submit a tgz containing - the PKGBUILD, scriptlets, patches, etc. The script will - unpack the tgz in an appropriate location and update the - backend database to 'register' the pacakge. - -8) TU package management - - A TU adopts a package from "Unsupported" and that shows users - and other TUs that the package is being reviewed. - - When the TU is ready to move the package to the AUR, they - use a custom utility/script that allows them to upload the - pkg.tar.gz (web uploads are inadequate for this process). - The upload utility/script has a server counterpart that - performs TU authentication and updates the database. - - A cronjob on the server can handle the new AUR package, - update the database, and rebuild the AUR sync db, and send - email notices to the TU about errors if any occur. - - The TUs should also be able to demote a package from the - AUR via the web interface. - - TUs will use cvs/svn interface (just like devs) to pull - down the PKGBUILD tree. This tree should reflect the same - layout as extra for easier package migration. They make - changes to their local copy, test, and then commit. They - use the xfer utility to upload the binary package to the - server. No shell access is required. - - -Automated Voting Tool (similar to ArchStats client) -===================== - -Requirements: -------------- - 1) Name of tool is 'pkgvote' - - 2) Requires registered account on web - email address not required - - 3) Casts 'yes' votes for all installed packages (except itself?) - -Implementation: ---------------- - A statically compiled C program that gathers the list of installed - packages and casts the vote to the web site. Very similar to the - way that ArchStats works now. When making the HTTP Post, it adds - a custom HEADER that the PHP script(s) can detect to know that it - is receiving a vote from a 'pkgvote' client. If the PHP script - does not see the special HEADER, it assumes it is a web browser - and gives the user HTML output. - - Once installed, the user edits the config file and supplies their - username/password. If no username/password exists in the config - file when it starts, it spits out an error message and exits. - +=================== +Arch User Repository (AUR) +=================== + +About: +===== +The Arch User Repository (AUR) is a framework for hosting a collection of +packaging scripts that are created and submitted by the Arch community. The +scripts contained in the repository (PKGBUILDS) can be built using the Arch +building/packaging script (makepkg) and installed via the Arch pacman manager +(pacman). The AUR project aims to provide the necessary web interface, database +schema, and scripts for a multi-lingual community-driven repository. + +Functionality: +========= +-Users may submit source packages that contain a PKGBUILD +-User accounts with varying permission levels (User, Trusted User, Developer) +-Ability to search for specific submitted packages (based on package name, +package description, package submitter, package maintainer) +-Display submitted package information by parsing PKGBUILD (description, +license, package dependencies, etc) +-Users can make comments on package information page +-Mark packages as out-of-date +-Vote for well-done and popular user submitted packages +-Trusted User and Developer have ability to search for and modify accounts +-Area for Trusted Users +and Developers to post AUR-related proposals and vote on them + +File Hierarchy: +========== + +Directory Layout: +------------------- +./po - Translation files for strings in the AUR web + interface. +./scripts - aurblup package blacklist tool. Scripts for AUR + maintenance. +./support - Schema for SQL database. Script for dummy data generation. +./web - Web interface for the AUR. + +Files: +------ +AUTHORS - List of maintainers, contributors, and translators for AUR + project. +COPYING - License information for AUR project (GPL version 2). +HACKING - Guidelines for modifying source and submitting + patches. +INSTALL - Installation procedure for AUR. +TODO - List of potential features and changes to be made to the AUR. +TRANSLATING - Directions for creating and updating string translations. +UPGRADING - Changes needed to upgrade older AUR version to newer version. + +Code: +===== +Official repository hosted at git://projects.archlinux.org/aur.git +See HACKING for information on submitting patches + +Bugs: +===== +Discovered bugs can be submitted to the AUR bug tracker: +https://bugs.archlinux.org/index.php?project=2 + +Contact: +======== +Questions, comments, and patches related to the AUR can be sent to the AUR +development mailing list: aur-dev@archlinux.org +Mailing list archives: http://mailman.archlinux.org/mailman/listinfo/aur-dev -- cgit v1.2.3-24-g4f1b