AUR Trusted User Guidelines

From ArchWiki
Revision as of 10:51, 24 July 2005 by Dibblethewrecker (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The TU

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 TUs are governed using the TU bylaws:

Guidelines for Package Maintenance

Accessing the Repo

Follow these instructions for uploading/modifying packages once you have become a TU:

  1. Install the "aurtools" package.
  2. Email Jason (<a class="email" href=""></a>) for a CVS account.
  3. Run the following commands to checkout the AUR CVS:
    export CVSROOT=":pserver:<userid>"
    cvs login
    cvs co community
  4. To add a PKGBUILD and other build files:
    cvs add <directory>
    cd <directory>
    cvs add PKGBUILD
    cvs commit
  5. To upload a binary package: tupkg --user <userid> --password <password> <packagefile.pkg.tar.gz>
  6. After uploading a package and committing the build files, tag the files with this command: cvs tag -cFR CURRENT <newpackagebuilddir>
  7. 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.

Adopting 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.

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.

Disowning packages

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.

TU getting started Tutorial

First, you should have the aurtools and cvs packages installed. aurtools is in [community], and contains everything you need to get going in order to submit and maintain your packages. cvs is in [current] and it's probably already on your system. Next, you should check out the AUR CVS. If you are not already familiar with CVS, it might be a wise investment, since the AUR and many other projects use it. Commands for checking out the CVS follow:

export CVSROOT=":pserver:<userid>" cvs login cvs co community

You should now have a new dir in your current working dir, called "community". Within it, you will find the CVS for TUs' AUR packages. They are grouped into categories, the same as those used on the web interface.

In order to ADD a package, you must copy all needed build files to the appropriate sub directory. Then, issue a "cvs add" on the new directory, as well as any needed build files within it (PKGBUILD, patches..etc). If you are in doubt..use existing ones as a model. Please include ONLY BUILD FILES, there is no need to include filelists, nor pkg/ nor src/ directories. Now, you must check in your changes (in this case additions), by issuing a "cvs commit". In addition, you must upload the binary package file using tupkg. The command should look something like this: "tupkg --user <userid> --password <password> <packagefile.pkg.tar.gz>". Following a successful binary upload, you should issue a "cvs tag -cFR CURRENT" on the builddir of the new package. The AUR daemon will not pick up anything that is not tagged CURRENT ! The daemon runs on a cronjob, every 10 minutes. Wait for the package to appear as an orphan on the web interface, and adopt it. You have now added your package.

In order to CHANGE a package, follow similar steps to those above, except just modify your files, issue the "cvs commit", upload the binary, and tag them CURRENT. It should get updated on the next sweep of the daemon.

You can avoid much of this hassle by using communitypkg (also included in aurtools). It is just like extrapkg, and devtools. In fact, it is entirely based on them. When we released communitypkg, I wrote a little doc on its usage, so I'm just going to point you to the archive of the mail, rather than explaining it again. There you go.

As usual, if you run into trouble or have any further questions, don't be afraid to contact me about it, I can probably help.

Happy Packaging!


AURtools Tutorial

I have updated the aurtools package in community, despite the fact that it is Paul's. Hope I didn't hurt anyone's feelings. The never version numbering reflects the version of the AUR that that tupkg was released as part of. This message is intended to inform the TUs of some major changes that have been made to this package. Although you may continue to do things as you have been doing (it's backwards compatible), you will find these a handy shortcut. The only real change to tupkg is that it now is able to use a config file, ~/.tupkg , instead of just taking command line options (though it still takes them). Any command line options will OVERRIDE settings in the config file. The config file should take the following format: ---BEGIN CONFIG FILE SNIP--- [tupkg] username = YOURUSERNAME password = YOURPASSWORD host = THEHOST port = THEPORT ---END CONFIG FILE SNIP--- Since the password needs to be plain-text, I suggest setting permissions on this file 600. The host and port options are OPTIONAL, and will default to and 1034, respectively, so these two options don't technically even need to appear in the file. Username and password are NOT quoted. If tupkg notices that this file exists, it will use options from it, saving you some typing on the command line. The second, and perhaps more exciting, new tool, is called communitypkg. Essentially, communitypkg is devtools for the community repo, and wraps the work of a cvs checkin, cvs tagging, and binary package uploading, all into one tool. In case there's confusion, I've included some sample sessions using communitypkg below so you get the idea, and even added some comments. ---Sample session, adding a new package--- export CVSROOT=":pserver:<userid>" cvs login cvs co community cd community/system # change a dir in the CVS tree we just checked out mv ~/stuff/aurtools . #copy over a build dir from wherever cvs add aurtools #ADD the DIRECTORY (non recursive) to the cvs repo cd aurtools

cvs add PKGBUILD #ADD any build files to the cvs repo makepkg #The package MUST be built in order to use communitypkg
communitypkg #this command, executed in the build dir, will:
  1. 1. Upload the binary file using tupkg
  2. 2. Do a cvs checkin, with a message of "upgpkg: $pkgname-$pkgver"
  3. 3. Do a cvs tag of it all to CURRENT

END sample session----

The package should now be uploaded and inserted, that's it!

Though communitypkg doesn't look like it simplifies anything in adding a package, it helps a bunch when upgrading. ---Sample upgrade session--- cd community/system/aurtools #Change to the dir in the CVS repo

  1. (you should've checked it out)
  2. Now do any PKGBUILD editing you may need to do

makepkg #as usual, the package MUST be built communitypkg #It does its thing ---END session--- Whallah! Your package is updated.

If you run into any trouble or have any questions, just drop me an email. Otherwise, happy packaging! And if for whatever reason it's not working, please remember that you may continue to do things the way you were doing them before, these changes are just shortcuts.