summaryrefslogtreecommitdiffstats
path: root/web
diff options
context:
space:
mode:
authorLoui Chang <louipc.ist@gmail.com>2008-08-20 00:10:29 +0200
committerLoui Chang <louipc.ist@gmail.com>2008-08-20 00:10:29 +0200
commit73f807a5a86c3ebd2f2de84b721c78271bd0cace (patch)
tree280f101977db0d619b28fa7bb65eeadd9f159dc0 /web
parentb69e2cce56bee61ea445417e29e55d27a15637d5 (diff)
downloadaur-73f807a5a86c3ebd2f2de84b721c78271bd0cace.tar.gz
aur-73f807a5a86c3ebd2f2de84b721c78271bd0cace.tar.xz
Remove obsolete Trusted User guidelines.
Guidelines are now maintained in the Arch wiki. Signed-off-by: Loui Chang <louipc.ist@gmail.com>
Diffstat (limited to 'web')
-rw-r--r--web/html/guidelines.html273
1 files changed, 0 insertions, 273 deletions
diff --git a/web/html/guidelines.html b/web/html/guidelines.html
deleted file mode 100644
index c2acd772..00000000
--- a/web/html/guidelines.html
+++ /dev/null
@@ -1,273 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"><head><title>AUR Guidelines</title>
-
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
- <link rel="stylesheet" type="text/css" href="http://archlinux.org/docs/css/arch-styles.css"></head>
-
-
-
- <body>
- <h1>AUR Guidelines</h1>
-
- <div class="date">Jun 08, 2005</div>
- <div class="version">1.1.0</div>
-
- <address>
- Ben Mazer
- <a class="email" href="mailto:blm@groknil.org">blm@groknil.org</a>
- </address>
- <address>
- The Trusted Users
- <a class="email" href="mailto:aur-general@archlinux.org">aur-general@archlinux.org</a>
- </address>
-
- <h2 id="summary">Summary</h2>
- <p>
- Basic guidelines for the Arch User Repository.
- </p>
-
- <h2 id="toc">Table Of Contents</h2>
- <div class="toc">
- <ol>
- <li><a href="#purpose">Purpose</a></li>
- <li><a href="#user">The User</a>
- <ol>
- <li><a href="#usersub">Submitting Packages</a></li>
-
- </ol>
- </li>
- <li><a href="#tu">The TU</a>
- <ol>
- <li><a href="#tuaddition">Adding a TU</a></li>
- <li><a href="#turemoval">Removing a TU</a></li>
- <li><a href="#otherduties">Other Duties</a></li>
-<li><a href="#tuguidelines">Guidelines for Package Maintenance</a>
- <ol>
- <li><a href="#accessing">Accessing the Repo</a></li>
- <li><a href="#adopting">Adopting a package</a></li>
- <li><a href="#disowning">Disowning a package</a></li>
- <li><a href="#pkgguidelines">Packaging Etiquette</a></li>
- </ol>
- </li>
-
-
- </ol> </li>
- <li><a href="#faq">Frequently Asked Questions</a></li>
- </ol>
- </div>
-
- <h2 id="purpose">Purpose</h2>
- <p>
- The <acronym title="Arch User Repository">AUR</acronym>
-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. <br><br> 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. </p>
- <h2 id="user">The User</h2>
- <p> 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:<br><br>
- <code>[community]<br>Server = ftp://ftp.archlinux.org/community/os/i686/</code><br><br>
-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. </p><h3 id="usersub">Submitting Packages</h3>
- <p>
-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
-(<b>no binaries</b>). Examples of what a directory looks like can be seen inside /var/abs. <br><br>
- When submitting a package, observe the following rules:
- </p><ul>
- <li>Check
-EXTRA, CURRENT, UNSTABLE, UNSUPPORTED, and AUR for the package. If it
-is inside any of those repositories in any form, do not submit the
-package (if the package is broken in some way, file a bug report). </li>
- <li>Verify
-carefully that what you are uploading is correct. Follow the
-TU/Developer Package Building Guidelines exactly. Broken packages make
-the AUR messy, and prevent the TUs from doing their other duties. </li>
- <li>If
-you are unsure about the package (or the build/submission process) in
-any way, submit the PKGBUILD to the AUR Mailing List for public review
-before adding it to the AUR.</li>
- <li>Make sure the package
-is useful. Will anyone else want to use this package? Is it extremely
-specialized? If more than a few people would find this package useful,
-it is appropriate for submission. </li>
- <li>Gain some experience before submitting packages. Build a few packages to learn the process and then submit. </li>
- <li>Do
-not abandon packages. While in UNSUPPORTED, it is the user's job to
-maintain the package. If you do not want to maintain the package for
-some reason, post a message to the AUR Mailing List. </li>
- </ul>
-
-
- <h2 id="tu">The TU</h2>
- <p>
-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. </p>
- <h3 id="tuaddition">Adding a TU</h3>
- <p>
-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. <br><br>
-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. <br><br>
-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. <br><br>
-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. <br>
-
- </p>
- <h3 id="turemoval">Sanctioning/Removing a TU</h3>
- <p>
-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. <br><br> 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. </p>
- <h3 id="otherduties">Other Duties</h3>
- <p>
-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. </p>
- <h3 id="tuguidelines">Guidelines for Package Maintenance</h3>
- <p>
- </p>
- <h4 id="accessing">Accessing the Repo</h4>
- <p>
- Follow these instructions for uploading/modifying packages once you have become a TU:
- </p><ol>
- <li>Install the "aurtools" package.</li>
- <li>Email Jason (<a class="email" href="mailto:jason@archlinux.org">jason@archlinux.org</a>) for a CVS account.</li>
- <li>Run the following commands to checkout the AUR CVS:<br>
- <kbd>
- export CVSROOT=":pserver:&lt;userid&gt;@cvs.archlinux.org:/home/cvs-community"<br>
- cvs login<br>
- cvs co community</kbd></li>
- <li>To add a PKGBUILD and other build files:<br>
- <kbd>
- cvs add &lt;directory&gt;<br>
- cd &lt;directory&gt;<br>
- cvs add PKGBUILD<br>
- .<br>
- .<br>
- cvs commit</kbd></li>
- <li>To upload a binary package:
- <kbd>tupkg --user &lt;userid&gt; --password &lt;password&gt; &lt;packagefile.pkg.tar.gz&gt;</kbd></li>
- <li>After uploading a package and committing the build files, tag the files with this command:
- <kbd>cvs tag -cFR CURRENT &lt;newpackagebuilddir&gt;</kbd></li>
- <li>Package
-changes should be available within 10 minutes. Verify everything was
-uploaded properly, then select the newly added or updated package in
-the web interface and set yourself as the maintainer.</li>
- </ol>
-
- <h4 id="adopting">Adopting Packages</h4>
- <p>
-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. <br><br>
-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. </p>
-
- <h4 id="disowning">Disowning packages</h4>
- <p>
-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. <br><br>
-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. </p>
- <h4 id="pkgguidelines">Packaging Etiquette</h4>
- <p>
- Adhere to the following rules when building/maintaining packages:
- <br>
- </p><ul>
- <li>Follow all rules in the <a href="http://www.archlinux.org/docs/en/guide/install/arch-install-guide.html#build">Arch Packaging Guidelines</a>.</li>
- <li>Always run Namcap on all packages and PKGBUILDs.</li>
- <li>All
-important messages should be echoed inside the .install file. For
-example, if a package needs extra setup to work, directions should be
-echoed. </li>
- <li>Any optional dependencies that aren't
-needed to run the package or have it generally function shouldn't be
-included, but a warning message inside the .install file should echo
-something like: "To enable SMB support, download the Samba package."</li>
-
- <li>Always look at current packages for ideas on how various problems should be handled. Most problems have already been solved. </li>
- <li>Dependencies
-are the most common packaging error. Namcap can help detect them, but
-it is not always correct. Verify dependencies by looking at source
-documentation and the program website. </li>
- <li>All packages should be buildable as a user, under fakeroot. </li>
- <li>New user creation should only be done when absolutely necessary. </li>
- <li>Always
-fill out all applicable fields in the PKGBUILD (never forget a URL,
-md5sum, etc). The LICENSE variable is not currently used, but will be
-very shortly. </li>
- <li>All custom variables should begin with an underscore (_). </li>
- <li>A PKGBUILD should never modify any files outside of the build directory. </li>
- </ul>
-
- <h2 id="faq">Frequently Asked Questions</h2>
- <p>
- Q: What is the difference between the AUR, COMMUNITY, and TUR? Why don't packages I upload to the AUR show up in pacman?<br><br>
-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.<br><br>
-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.<br><br>
-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. </p>
- </body></html>