summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorcanyonknight <canyonknight@gmail.com>2012-05-23 19:17:04 +0200
committerLukas Fleischer <archlinux@cryptocrack.de>2012-07-06 11:25:34 +0200
commit58de6280fdadd29fba1c550a25de714c1d543c61 (patch)
treec1eb6c16a554b0f43e50577ab5c2000814b763b3
parentf014d7f76390a79b09aebe7cd4bfe508fdbe1a6d (diff)
downloadaur-58de6280fdadd29fba1c550a25de714c1d543c61.tar.gz
aur-58de6280fdadd29fba1c550a25de714c1d543c61.tar.xz
Update AUR README
Old README file is severely outdated, update with current information. Signed-off-by: canyonknight <canyonknight@gmail.com> Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>
-rw-r--r--README174
1 files 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