JeroenVanMeeuwen/Revisor/DevelHowto

= Developing on Revisor =

Here's a few quick notes on developing for Revisor.

= Obtaining the Source =

The source can be obtained from our fedorahosted.org source repository, using git:

Anonymous users should use:

$ git clone git://git.fedorahosted.org/git/revisor

while users with access to push commits to the revisor source repository should use:

$ git clone ssh://git.fedorahosted.org/git/revisor

This creates a directory  in the current directory with branch master.

Running Revisor From Source
Note: Revisor cannot run from source on a system that has the Revisor RPM installed.

Revisor of course has a couple of dependencies on other programs so you should install these:

busybox-anaconda notify-python usermode pam python automake intltool gettext desktop-file-utils

Now you can let automake generate some of the files needed to run Revisor. Navigate to the revisor source tree directory you have just created with cloning:

$ autoreconf -v && ./configure

Once automake is done, and configure has completed, all the files are in place; but Revisor still needs a way to find these files. Although it is possible to manually symlink some of the directories Revisor looks at, to the location where they live in the source repository, we recommend you use  which should make exercise this as painless as possible. Note that this script forcibly deletes some of the directories Revisor would have owned if it were installed on the system, and as such if you had Revisor installed previously, you might want to check if you have any (important) files left in those directories, such as highly customized kickstart configuration files.

The  script does the following: 1. In Revisor 2.1.0 (development version in branch master), this includes: 2. In Revisor 2.0.5 (branch 2.0.5), this includes:
 * Symlink  to   so that   primary configuration file and the   configuration directory are valid (the symlink causes the actual file and directory to be found in  )
 * Create the  directory so that a couple of symlinks can be created from within that directory:
 * In Revisor 2.1.0, also create symlinks from within the appropriate  directories to the source for these man pages in  .
 * In Revisor 2.1.0, also create symlinks from within the appropriate  directories to the source for these man pages in  .
 * In Revisor 2.1.0, also create symlinks from within the appropriate  directories to the source for these man pages in  .
 * In Revisor 2.1.0, also create symlinks from within the appropriate  directories to the source for these man pages in  .

From this moment on, you should be able to run:

$ ./revisor.py

Note that revisor needs root privileges to run, and that you'll need to  or   to gain those. Use here whatever you find the most convenient; Revisor though should have a nice error message when ran without those privileges.

Installing the Required Packages for Revisor Modules
The modules available with Revisor each have their own package dependencies. You need to install those if you start developing on them. Running Revisor from source with the  switch shows you more details:

To be done with it once and for all, run:

rpmbuild rpmdevtools python-virtinst

Building Revisor
To build the Revisor RPM packages, run:

bin/revisor-build

This should run:

autoreconf -v ./configure

make mock

make srpm make rpm

rpmlint /path/to/rpm

Note that if you have added files to the tree, you should at least make Automake aware of these files.

= Developing =

Branches
Each target has (or should have) it's own branch:


 * EL-5
 * F-7
 * F-8

A rule of thumb is, that each release gets a tag in it's corresponding branch. Say if you were to release 2.1.0-1 for F-7, you would tag 2.1.0-1.fc7. Tags need to be unique amongst branches, so unless you have a release to all branches... Add the dist-tag.

Once you do tag and make build anything in koji, you will also need to upload the files (tar.gz & spec and/or srpm) to http://files.revisor.fedoraunity.org/

Switching Branches
To switch branches, first clone the source repository like described in "Obtaining the Source" earlier on this page. Then, create a local branch with the same name as the upstream branch, using a reference point such as a tag:

$ git branch 2.0.5 2.0.5-13

Edit  and add a   section:

[branch "master"] remote = origin merge = refs/heads/master

[branch "2.0.5"] remote = origin merge = refs/heads/2.0.5

Check out the branch:

$ git checkout 2.0.5

and pull in the latest changes:

$ git pull

Working On Different Branches
Usually though, what I do, is create separate clones for each branch (append a directory name to the  command), so that I can change things in one branch and without having to commit them, change to another branch. Here's an example of me using branch 'master' and '2.0.5':

$ pwd /home/jmeeuwen/devel/revisor

$ git clone ssh://git.fedorahosted.org/git/revisor 2.0.5 Initialized empty Git repository in /home/jmeeuwen/devel/revisor/2.0.5/.git/ remote: Generating pack... remote: Done counting 7477 objects. remote: Deltifying 7477 objects. remote: 100% (7477/7477) done Indexing 7477 objects... remote: Total 7477, written 7477 (delta 5378), reused 0 (delta 0) 100% (7477/7477) done Resolving 5378 deltas... 100% (5378/5378) done

$ git clone ssh://git.fedorahosted.org/git/revisor master Initialized empty Git repository in /home/jmeeuwen/devel/revisor/master/.git/ remote: Generating pack... remote: Done counting 7477 objects. remote: Deltifying 7477 objects. remote: 100% (7477/7477) done Indexing 7477 objects... remote: Total 7477, written 7477 (delta 5378), reused 0 (delta 0) 100% (7477/7477) done Resolving 5378 deltas... 100% (5378/5378) done

$ ls -l total 8 drwxrwxr-x 14 jmeeuwen jmeeuwen 4096 2007-11-24 00:53 2.0.5 drwxrwxr-x 13 jmeeuwen jmeeuwen 4096 2007-11-20 21:23 master

$ cd 2.0.5 $ git branch 2.0.5 2.0.5-13 $ git checkout 2.0.5 $ git branch -D master Deleted branch master. $ vi .git/config

[branch "2.0.5"] remote = origin merge = refs/heads/2.0.5

$ git pull Updating cc12a50..a45e773 Fast forward Makefile.am     |   13 +++++++++ revisor.py      |    2 + revisor.spec.in |    5 +++- revisor/base.py |    5 +++ revisor/cfg.py  |   10 +++++++ revisor/pungi.py |  72 +++++++++++++++++++++++++++++++++++++++++++++++++++++- 6 files changed, 105 insertions(+), 2 deletions(-)

I can't really imagine this is best practice though ;-)