Twas brillig at 14:45:05 05.03.2009 UTC+01 when did gyre and 

 mfk> I hope that's not asking too much, and sorry for the late reply!

Well, we really need some introductory information for gear. Thanks for
forcing me for finally writing it down :) I will keep page updated with all the stuff
discussed here.

Looks like it's a big task, so I'll split it to the several mails. In
this one I will describe simple (if not simplistic) workflow dubbed
"like SRPM".

First of all, let's brush up some 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 I can think of right now:
- like SRPM
- with patches on separate branch
- with 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:

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.

1. 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

2. Adding spec and patches

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

3. 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.

4. 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.

5. 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).


Attachment: pgpnzyRMemKDg.pgp
Description: PGP signature

vcs-pkg-discuss mailing list

Reply via email to