Gear/Introduction

Gear Introduction

This is an introduction to gear for the people who already have the RPM packaging experience.

RPM-specific stuff

RPM source packages are built from the following files:

.spec file, which is roughly debian/* without debian/patches/*
several source files/tarballs
and several patch-files.

gear provides the means to build/generate all three types of files from the git, so repository is not required to contain them in the form digestible by rpmbuild.

Working with upstream source code

Upstream source code is generally stored in the separate branch.

There are two main sources of source code: upstream tarballs or upstream VCS, plus importing SRPMs for keeping older packaging history.

SRPMs

$ gear-srpmimport some.src.rpm

will import the given SRPM to the branch ("srpms" by default) in the repository (like git-import-dsc).

Importing SRPM creates git layout similar to the "Like SRPM" scenario described below.

Tarballs

$ gear-update foo-2.0.tar.gz tar

will update the subdirectory tar in git repository with contents of tarball. This operation is similar to the git-import-orig from dpkg-buildpackage. As SRPMs may contain several sources, the source code usually stored in the subdirectory.

Upstream VCS

This should be obvious: just fetch/pull if upstream uses git, or use converter if it does not.

Packaging and patching

There are three major scenarios:

like SRPM
patches in one branch
patches in topic branches

Scenario 1. "Like SRPM"

This is least useful, but simple scenario. git is used just for keeping history, and the usual maintainer's workflow is not changed.

Branches in repository:

master
upstream

Tree layout:

foo/                      (in upstream, master)
.gear/rules               (in master)
foo.spec                  (in master)
foo-something-fixed.patch (in master)
foo-another-fixed.patch   (in master)

git repository is generated by the importing SRPMs or by creating from scratch.

Importing tarball to the upstream branch

By using master branch to make it a bit easier

$ mkdir foo
$ cd foo
$ git init foo
$ gear-update ../foo-1.0.tar.gz foo
$ git checkout -b upstream

Adding spec and patches

$ vi foo.spec
$ vi foo-something-fied.patch
$ vi foo-another-fixed.patch

Adding gear/rules

The .gear/rules will have the following contents:

 copy: foo-something-fixed.patch
 copy: foo-another-fixed.patch
 tar.gz: foo

This will add both patches and tar.gz'ed directory foo/ to the buildroot where the package is built.

Specfile is picked up automatically if there is only .spec in the root directory fo git.

Commiting the stuff

gear is picky about it - it only handles the stuff which is in repo.

$ git add ...
$ gear-commit # this is wrapper around git-commit which uses the last
              # changelog entry as a commit message.

Building it

$ gear-rpm

Here the .gear/rules is consulted and the following is performed:

temporary directory is created
all the files mentioned in .gear/rules are copied to this directory according to the rules
rpmbuild is invoked.

There are also another build-commands: gear-hsh (uses hasher build tool) and gear-remote-rpm/gear-remote-hsh, which use remote host for actual building (communicating over SSH).