diff options
Diffstat (limited to 'data')
| -rw-r--r-- | data/pkgmaint_guide.txt | 164 |
1 files changed, 164 insertions, 0 deletions
diff --git a/data/pkgmaint_guide.txt b/data/pkgmaint_guide.txt new file mode 100644 index 00000000..85106eab --- /dev/null +++ b/data/pkgmaint_guide.txt @@ -0,0 +1,164 @@ +============================================================================= + THE QUICK AND DIRTY ON HOW TO BE A PACKAGE MAINTAINER +============================================================================= + questions to jvinet@zeroflux.org + +1. Follow Package Guidelines + + Package guidelines can be found in the Arch Linux documentation. + Please follow them closely. + +2. How To Use CVS + + The example commands below assume the module 'extra'. + + 2.1 Make sure your CVSROOT environment variable is set properly. If the + CVS repository is on the same box: + # export CVSROOT=/home/cvs-extra + + If you want to access the repository from the different box via SSH: + # export CVS_RSH=ssh + # export CVSROOT=:ext:user@cvs.archlinux.org:/home/cvs-extra + + 2.2 Checkout the repository. This will download the entire repository to + your local machine: + # cvs co extra + + 2.3 Updating the repository. This syncs your local repository with the + master. You should do this often, especially if other people could be + working on the same repository. + # cd extra + # cvs -q update -d + + 2.4 Adding files/directories to the repository. When you want to add a new + package you should create a directory under the respective category and + place the new PKGBUILD in it. For example, to add fvwm to the repo: + # cd extra/x11 + # mkdir fvwm + # cd fvwm + # cp /var/abs/PKGBUILD.proto ./PKGBUILD + <edit, test, build, etc> + # cd .. + # cvs add fvwm + # cvs add fvwm/PKGBUILD + + 2.5 Committing changes. Files are not written to the master repository until + you commit. Never forget to commit! + # cd extra + # cvs commit + + This will find all modified files, then throw you into vi where you can + add a log message describing your changes. Save and exit from vi when + you're done and cvs will update the files in the master repository. + + 2.6 Removing files. If you need to remove a file (eg, an old patch that + isn't needed anymore), you can do the following: + # cd extra/x11/fvwm + # rm old.patch + # cvs remove old.patch + # cvs commit -m "removed old.patch" old.patch + also remove the CURRENT/STABLE tags from the file so it does not appear + in ABS any more: + # cvs tag -d CURRENT old.patch + + Don't forget to commit afterwards! Remember that no changes are made + to the master until you commit. + + 2.7 Removing directories cannot be done easily. If you really need to + remove a directory, email the sysadmin (Judd) and I'll help you out. + + 2.8 Tagging files. Every file in CVS has tags associated with it, which + allows us to select certain versions of scripts. The db generation + scripts will only look at files that are tagged as CURRENT, so you need + to tag all files after you commit them: + # cd extra/x11/fvwm + # cvs tag -c -F -R CURRENT + + NOTE: When tagging, you should be sure to ONLY tag the updated files, + not the entire repository. Otherwise, if parts of your checkout are + out-of-date, you may actually be tagging an OLDER version of a file, + reversing someone else's tag procedure. + +3. The Process + + 3.1 Checkout/update your local repository from cvs.archlinux.org + 3.2 Make any changes you need to + 3.3 Put your new packages in your local staging directory on archlinux.org. + Suggested syntax is: + scp name-ver-rel.pkg.tar.gz you@archlinux.org:staging/extra/add + 3.4 Commit your changes (section 2.5) + 3.5 Update the CURRENT tags to new revisions (section 2.8) + 3.6 Log in to archlinux.org and run the /arch/db-extra script, which + will re-generate the sync db and place it in /home/ftp/extra, then + move the new/updated packages from your staging directory to the + FTP tree. + 3.7 Remove any older versions of packages from /home/ftp/extra to + save diskspace, they should be noted when the db generation script + finishes. + + Make sure you do things in this order, mixing them up can break things + temporarily. For example, if you remove older versions from the ftp + tree before you update the database or update the database before + uploading new packages, arch users trying to download the package at + that time will get "file not found" errors. + +4. Staging Directories + + As mentioned in Section 3, packages need to be uploaded to the proper + staging directory before running a db generation script. The staging + area (located in your home dir) looks like so: + + staging + |-- arch + | |-- add + | `-- del + |-- extra + | |-- add + | `-- del + |-- testing + | |-- add + | `-- del + `-- unstable + |-- add + `-- del + + As you can see, each repository has two staging directories: "add" and + "del". When you want to add or update a package, you'll place it in the + "add" directory for the repository you're working in. Then run the db-gen + script. + + When you want to remove a package, you will move the package OUT OF the FTP + directory (eg, /home/ftp/extra/os/i686/) and INTO the "del" directory for + the repository you're working in. Once moved, you can run the db-gen + script -- it will see that the file has left the FTP tree and will remove + it from the package database. + +5. Miscellaneous Stuff + + 5.1 If you are creating a daemon you need to include an rc.d startup + script for it. Look at /var/abs/daemons/esd for a simple example. + 5.2 Please include a line that says '# $Id: pkgmaint_guide.txt,v 1.3 2006/10/05 20:52:01 judd Exp $' at the top of each + PKGBUILD. This will be parsed by cvs during a commit, and replaced + with user/timestamp data. + 5.3 Please do some rudimentary checks of the package before making it + 'live'. Try installing it and see if there are any file conflicts. + Check for dependencies by running 'ldd' against the binaries and + looking through the .so files it requires. For example, + 'ldd /usr/bin/gvim' returns a big list of libs, one of which is + libgtk-x11-2.0.so.0, so gtk2 should be one of the dependencies for + gvim. Also, namcap is available in the extra repository. Running it + against a package will print dependancy warnings as well as possible + configuration problems. Namcap is not the final word, if ldd or + runtime show otherwise, believe them instead. + 5.4 When creating a package description for a package, do not include + the package name in a self-referencing way, as it is redundant. + For example, "Nedit is a text editor for X11" could be simplified to + "A text editor for X11". Also try to keep the descriptions to ~80 + characters or less. + 5.5 When entering cvs log messages for new/upgraded packages, please use + these tags so they can be easily parsed for changelog generation: + if the package is upgrade use: 'upgpkg: pkgname newpkgver' + if the package is new use: 'newpkg: pkgname newpkgver' + + +$Id: pkgmaint_guide.txt,v 1.3 2006/10/05 20:52:01 judd Exp $ |