summaryrefslogtreecommitdiff
path: root/templates/devel
diff options
context:
space:
mode:
authoreliott <eliott@cactuswax.net>2007-12-29 15:34:02 -0800
committereliott <eliott@cactuswax.net>2007-12-29 15:34:02 -0800
commit15ceff77fef19819cba43e866938311aeffd0732 (patch)
tree16903554adbb32300aad9a5b3d647679710e9302 /templates/devel
parentd1cc0f54a490e5eacf07107e461672979266f461 (diff)
Modified render_template and renamed it to render_response (consistent with
archweb_pub conventions). Moved pkgmaint_guide to a template.
Diffstat (limited to 'templates/devel')
-rw-r--r--templates/devel/pkgmaint_guide.txt164
1 files changed, 164 insertions, 0 deletions
diff --git a/templates/devel/pkgmaint_guide.txt b/templates/devel/pkgmaint_guide.txt
new file mode 100644
index 00000000..85106eab
--- /dev/null
+++ b/templates/devel/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 $