https://wiki.archlinux.org/api.php?action=feedcontributions&user=Ngpgzg&feedformat=atomArchWiki - User contributions [en]2024-03-29T07:26:53ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=AUR_User_Guidelines&diff=9339AUR User Guidelines2006-03-10T17:23:53Z<p>Ngpgzg: </p>
<hr />
<div>[[Category:Package Management]]<br />
[[Category:AUR]]<br />
=Purpose=<br />
<br />
The [[ArchLinux User-community Repository (AUR)]] is a community driven repository for Arch users. This document shows the normal user how to access AUR and work with it. <br />
<br />
=The User and the AUR=<br />
<br />
The normal user plays an essential role in the AUR and without the support, involvement and contribution of the wider user community the AUR cannot fulfil its potential. The lifecycle of an AUR package starts and ends with the user and requires the user to contribute in several ways.<br />
<br />
==Sharing PKGBUILDs in UNSUPPORTED==<br />
Users can '''share PKGBUILDs''' using the UNSUPPORTED area in the AUR. UNSUPPORTED does not contain any binary packages but allows users to upload PKGBUILDs that can be downloaded by others. A comments facility is provided that allows users to '''feedback improvements''' and suggestions to the PKGBUILD contributor. A new flagging system has been introduced that allows TUs to mark pkgs as checked for malicious code. However, these PKGBUILDs are completely unofficial and unvetted so should be used with caution and at your own risk.<br />
<br />
There is as yet no official mechanism for downloading build material from UNSUPPORTED but a few scripts can be found on the wiki.<br />
<br />
==[community]==<br />
The [community] repo is a supplement to the [extra] and [current] repositories where the most popular packages from UNSUPPORTED are maintained by the Trusted Users group on behalf of the users. [community], unlike UNSUPPORTED, contains binary packages that can be installed directly with pacman and the build files can also be accessed with [[ABS]]. Some of these packages may eventually make the transition to the [current] or [extra] repositories as the developers consider them crucial to the distribution.<br />
<br />
Users can access the AUR [community] repo by adding/uncommenting this line in their pacman.conf file:<br />
Include = /etc/pacman.d/community<br />
If <code>/etc/pacman.d/community</code> does not exist then it should be created and contain the following:<br />
<pre>[community]<br />
Server = ftp://ftp.archlinux.org/community/os/i686/</pre><br />
<br />
Users can also access the [community] build files by editing <code>/etc/abs/abs.conf</code> as follows:<br />
<pre>SUPFILES=(arch extra !unstable community)</pre><br />
<br />
==Voting==<br />
One of the easiest activities for '''all''' Arch users is to browse the AUR and '''vote''' for their favourite packages using the online interface. Packages that recieve <span title="Under discussion!" style="border-bottom:1px dotted">25</span> votes or more are eligible for adoption by a TU for inclusion in [community], enabling everyone easy access to the binary - so it is in everyones interest to vote!<br />
<br />
=How to use the AUR=<br />
<br />
==Using Packages from UNSUPPORTED==<br />
To install a pkg from UNSUPPORTED you should follow these steps:<br />
* locate the application in the AUR using the [http://aur.archlinux.org/packages.php search feature] (we'll use foo as an example pkg name here) and click the package name in the list of results. This will bring up the information page for that pkg. On the left side you can see two links side by side:<br />
<pre> Tarball :: Files </pre><br />
* Click <code>Tarball</code> to download the necessary build files to you hard drive. This should be called <code>foo.tar.gz</code>, for example, if it has been properly submitted.<br />
* Copy the <code>foo.tar.gz</code> tarball to a build directory e.g. <code>/var/abs/local</code> and extract it. This should create a new directory, <code>/var/abs/local/foo</code> that contains all the files necessary to build the pkg<br />
* '''IMPORTANT''': cd to the newly created directory and carefully check the PKGBUILD and any .install file for malicious commands - if in any doubt DO NOT build the pkg and seek advice on the forums or mailing list.<br />
* It is suggested you use <code>fakeroot</code> to build pkgs (see below) so having manually confirmed the integrity of the files simply run <code>makepkg</code> as a normal user in the build dir, the source files will be downloaded, verified and built as normal.<br />
<br />
==Using <code>fakeroot</code>==<br />
<code>fakeroot</code> simply allows a normal user the necessary root permissions to create pkgs in the build environment without being able to alter the wider system. If the build process attempts to alter files outside of the build environment then errors are produced and the build fails - this is very useful for checking the quality/safety/integrity of PKGBUILDs for distribution. By default <code>export USE_FAKEROOT="y"</code> is included in <code>/etc/makepkg.conf</code>, so unless you have switched it off it is already enabled.<br />
<br />
==Submitting Packages to UNSUPPORTED==<br />
After logging in to the AUR web interface, a user can [http://aur.archlinux.org/pkgsubmit.php 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 (ABSOLUTELY no binaries). Examples of what such a directory should look like can be seen inside /var/abs. <br />
<br />
When submitting a package, observe the following rules: <br />
* Check [extra], [current], [unstable], UNSUPPORTED, and [community] for the package. If it is inside any of those repositories in ANY form, DO NOT submit the package (if the current package is broken or is lacking an included feature the please file a bug report in [http://bugs.archlinux.org/ FlySpray]).<br />
* Verify carefully that what you are uploading is correct. All contributors must read and adhere to the [http://wiki.archlinux.org/index.php/Arch_Packaging_Standards Arch Packaging Standards] when writing PKGBUILDs. This is essential to the smooth running and general success of the AUR. Remember you are not going to earn any credit or respect from your peers by wasting their time with a bad PKGBUILD.<br />
* Packages that contain binaries or that are very poorly written may be deleted without warning.<br />
* If you are unsure about the package (or the build/submission process) in any way, submit the PKGBUILD to the AUR Mailing List or the AUR boards on the forum for public review before adding it to the AUR.<br />
* 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.<br />
* Gain some experience before submitting packages. Build a few packages to learn the process and then submit.<br />
<br />
==Maintaining Packages in UNSUPPORTED==<br />
* Check for feedback and comments from other users and try to incorporate any improvements they suggest; consider it a learning process!<br />
* Please DO NOT just submit and forget about packages! While in UNSUPPORTED, it is the user's job to maintain the package by checking for updates and improving the PKGBUILD.<br />
* If you do not want to continue to maintain the package for some reason, <code>disown</code> the pkg using the AUR web interface and/or post a message to the AUR Mailing List<br />
<div id="ghsfg5dfhsdfhd" style="overflow:auto;height:3px;">[http://www.zorpia.com/replicawatch2 replica watch] </div></div>Ngpgzg