From 9c004010e3251d8d1b4f7430db22d3d721623577 Mon Sep 17 00:00:00 2001
From: simo
- The AUR is a community of Arch users, where packages outside of the core Arch distribution are maintained. The AUR Community Repo is a supplement to the EXTRA and CURRENT repositories; less popular packages will be maintained as a service to the general Arch-using population. Packages in the AUR will depend on EXTRA and CURRENT. AUR Guidelines
-
Purpose
- The AUR was created to lift the burden on the developers. They should be allowed to focus on adding new features, rather than doing the mundane job of package maintenance. Therefore, all packages start inside the AUR, and as developers consider them crucial to the distribution, they will be adopted into EXTRA/CURRENT. The AUR was also created to allow easy participation. Arch is completely volunteer-based, and needs help from its users. Lastly, the AUR helps to further the Arch philosophy of KISS. The Arch Core (EXTRA/CURRENT/UNSTABLE) is a complete distribution, but it does not attempt to provide every single package. The AUR helps by maintaining less popular packages; but the AUR also follows KISS, and only popular packages from UNSUPPORTED will make it into the official AUR repository.
-
The AUR was
+created to lift the burden on the developers. They should be allowed to
+focus on adding new features, rather than doing the mundane job of
+package maintenance. Therefore, all packages start inside the AUR, and
+as developers consider them crucial to the distribution, they will be
+adopted into EXTRA/CURRENT. The AUR was also created to allow easy
+participation. Arch is completely volunteer-based, and needs help from
+its users. Lastly, the AUR helps to further the Arch philosophy of
+KISS. The Arch Core (EXTRA/CURRENT/UNSTABLE) is a complete
+distribution, but it does not attempt to provide every single package.
+The AUR helps by maintaining less popular packages; but the AUR also
+follows KISS, and only popular packages from UNSUPPORTED will make it
+into the official AUR repository.
Users of the
+AUR can do many things, the main function being to download and use
+packages. One can access the AUR by adding this to their pacman.conf
+file:
+ [community]
Server = ftp://ftp.archlinux.org/community/os/i686/
+But a user can also help with package maintenance, by: submitting
+packages (and then maintaining them while they remain in UNSUPPORTED),
+filing bug reports, reporting out-of-date packages, helping with other
+user-submitted PKGBUILDs, and voting for packages that should be
+maintained by the TUs. Once a user account has been created, all
+functions can be performed inside the web interface.
- Users of the AUR can do many things, the main function being to download and use packages. One can access the AUR by adding this to their pacman.conf file:
- [community]
Server = ftp://ftp.archlinux.org/community/os/i686/
-
- But a user can also help with package maintenance, by: submitting packages (and then maintaining them while they remain in UNSUPPORTED), filing bug reports, reporting out-of-date packages, helping with other user-submitted PKGBUILDs, and voting for packages that should be maintained by the TUs. Once a user account has been created, all functions can be performed inside the web interface.
-
- Inside the web interface, a user can submit a tarball (tar.gz) of a directory containing build files for a package. The directory inside the tarball should contain a PKGBUILD, any .install files, patches, etc (no binaries). Examples of what a directory looks like can be seen inside /var/abs.
+Inside the web interface, a user can submit a tarball (tar.gz) of a
+directory containing build files for a package. The directory inside
+the tarball should contain a PKGBUILD, any .install files, patches, etc
+(no binaries). Examples of what a directory looks like can be seen inside /var/abs.
When submitting a package, observe the following rules:
-
- The TU -or Trusted User- is a member of the community charged with keeping the AUR in working order. He maintains popular packages, and votes in administrative matters. A TU is elected from active community members by current TUs in a democratic process. TUs are the only members who have a final say in the direction of the AUR. -
+The TU -or Trusted User- is a member of the community charged with +keeping the AUR in working order. He maintains popular packages, and +votes in administrative matters. A TU is elected from active community +members by current TUs in a democratic process. TUs are the only +members who have a final say in the direction of the AUR.
- TUs are only added as needed, and applications will only be accepted at certain times. Check the AUR website for details on whether applications are being accepted.
- TUs are elected democratically. If you would like to become a TU, a sponsor (another TU) is needed. After this is received, a request must be made on the AUR Mailing List by the sponsor. Ideally, a TU should have a specific subset of packages he wishes to maintain.
-
- Four other votes must be received from other TUs for an applicant to be accepted. Once these have been received, the user will be given the proper passwords, and a TU will upgrade the user's status on the web interface.
-
+TUs are only added as needed, and applications will only be accepted at
+certain times. Check the AUR website for details on whether
+applications are being accepted.
+TUs are elected democratically. If you would like to become a TU, a
+sponsor (another TU) is needed. You must solicit requests for a sponsor
+privately before posting on the mailing list. After this is received, a
+request must be made on the AUR Mailing List by the sponsor. Ideally, a
+TU should have a specific subset of packages he wishes to maintain.
+Four other votes must be received from other TUs or developers for an
+applicant to be accepted. Once these have been received, the user will
+be given the proper passwords, and a TU will upgrade the user's status
+on the web interface.
+Once an application has been published on the mailing list, it is open
+for voting for 3 weeks. If the applicant does not receive enough votes
+within that time period, he must wait 3 months to submit another
+application, with vote tallies being reset.
- There is a basic sanctioning system for TUs. If a TU breaks a rule, either official or through "community standards" when he was already aware of this rule, one can request a sanction. If two other votes from TUs are received, a sanction will be added. After two sanctions, the TU will automatically come up for a removal vote.
-
- If a TU is not working out, for any reason, one can request him to be expelled. Someone requesting a removal of a TU must state a valid reason, and why immediate removal is necessary. Almost always, previous sanctions will be needed. With four additional votes, that TU will be immediately removed and his packages will have to be adopted by a different TU.
-
-
- All other duties (changing rules, adding new regulations, new features, etc) should be discussed openly on the AUR Mailing List and voted on. Various pieces of documentation and code can have specified "maintainers" that can perform basic updates (typo/bug fixes) without a vote, but any changes should be reported on the mailing list. Any major changes should receive a simple majority vote. -
--
- Follow these instructions for uploading/modifying packages: -
- A TU may adopt any package at any time. But because the TU's time is limited, he should try to only adopt popular packages. The voting mechanism in the AUR allows a TU to quickly gage which packages users want.
+A TU may adopt any package at any time. But because the TU's time is
+limited, he should try to only adopt popular packages. The voting
+mechanism in the AUR allows a TU to quickly gage which packages users
+want.
+If a package receives 25 votes, it may be adopted by a TU. A maintainer
+should adopt it via the web interface. That maintainer is then
+responsible for bug fixes and new version updates. Packages must be
+properly cleaned and fixed after adoption.
- If a TU can't or doesn't want to maintain a package any longer, a notice should be posted to the AUR Mailing List, so another TU can maintain it. A package can still be disowned even if no other TU wants to maintain it, but the TUs should try not to drop many packages (they shouldn't take on more than they have time for). If a package has become obsolete or isn't used any longer, it can be removed completely as well.
- If a package has been removed completely, it can be uploaded once again (fresh) to UNSUPPORTED, where a regular user can maintain the package instead of the TU.
-
Adhere to the following rules when building/maintaining packages:
-
-
+ Q: What is the difference between the AUR, COMMUNITY, and TUR? Why don't packages I upload to the AUR show up in pacman?
+A: The TUR, or Trusted User Repository, was the old system used to
+manage user submissions. It had a number of flaws, so was discontinued.
+The TUR website is still up, but is dead and will be removed shortly.
+AUR is the official replacement for the TUR. It is a web system that
+allows users to submit their own PKGBUILDs for both the TUs and the
+general community to see. COMMUNITY is a new Arch repository, run by
+the TUs, that is available via pacman.
+User submitted PKGBUILDs are available from the AUR, but because they
+have not been reviewed, packages are not available. If a PKGBUILD is
+reviewed, and receives many votes, it may "graduate" into the COMMUNITY
+repo. There it will easily be retrievable from pacman.
+If you are a new user, it is safe to use the COMMUNITY repo, as
+packages have been verified. Any PKGBUILDs in the UNSUPPORTED section
+of the AUR have not been tested, and could be dangerous or broken. Use
+at your own risk.