Commit 58de6280 authored by canyonknight's avatar canyonknight Committed by Lukas Fleischer
Browse files


Old README file is severely outdated, update with current information.
Signed-off-by: default avatarcanyonknight <>
Signed-off-by: default avatarLukas Fleischer <>
parent f014d7f7
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.
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
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)
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?)
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)
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.
-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
./scripts - aurblup package blacklist tool. Scripts for AUR
./support - Schema for SQL database. Script for dummy data generation.
./web - Web interface for the AUR.
AUTHORS - List of maintainers, contributors, and translators for AUR
COPYING - License information for AUR project (GPL version 2).
HACKING - Guidelines for modifying source and submitting
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.
Official repository hosted at git://
See HACKING for information on submitting patches
Discovered bugs can be submitted to the AUR bug tracker:
Questions, comments, and patches related to the AUR can be sent to the AUR
development mailing list:
Mailing list archives:
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment