Gear/Introduction: Difference between revisions
(New page: == 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...) |
|||
Line 10: | Line 10: | ||
* and several patch-files. | * and several patch-files. | ||
gear provides the means to build/generate | gear provides the means to build/generate latter two types of files from | ||
the git, so repository is not required to contain them in the form | the git, so repository is not required to contain them in the form | ||
digestible by rpmbuild. | digestible by rpmbuild. |
Revision as of 19:29, 5 March 2009
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 latter two 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).