Project

General

Profile

Download (5.17 KB) Statistics
| Branch: | Tag: | Revision:

foreman-packaging/README.md @ d1e835d9

rpm packaging branches

The rpm/* branches contain RPM spec files for Foreman's dependencies and
related projects (mostly rubygems).

Requirements

If you're just submitting a fix, you don't need anything special.

If you're just submitting a patch which changes a source file, you will need:

However to release RPMs from this repo, you also require:

  • koji client and an account (certificate) on koji.katello.org
  • tito 0.5.4 or higher

HOWTO: checkout

Run:

  • git clone https://github.com/theforeman/foreman-packaging -b rpm/develop
  • git annex init to set up this repo for using git annex
  • ./setup_sources to register git-annex file URLs

HOWTO: test a package

Before committing and tagging a build, please test it.

lzap's sbu utility is
good for this:

  1. sbu (defaults for EL6 with SCL)
  2. sbu katello fc19 foreman-nightly-fedora19
  3. sbu katello el6 foreman-nightly-nonscl-rhel6

Most packages should build for EL6 with SCL and Fedora 19.

HOWTO: create a new core package or dependency

  1. Check if it's available in Fedora:
  2. If available in Fedora, copy the spec from the SCM link on the left
  3. Copy the template/ directory
    1. rename the spec file, don't use an SCL prefix
    2. update gem_name, version, ensure "Release" is 1
    3. empty the %changelog section
  4. Follow the "test a package" section above until it builds for all targeted platforms and required SCL + non-SCL modes.
  5. Download the source file (e.g. the .gem) into the spec directory and run git annex add foo.gem
  6. Update rel-eng/releasers.conf
    • If building for Fedora, add to the "foreman-nightly-fedora19" whitelist
    • If building non-SCL only, add to the "foreman-nightly-rhel6" blacklist
    • If building SCL EL6 only, no action required
  7. Update comps/comps-foreman-*.xml
  8. Commit the changes
    1. git add -A
    2. git commit -m "Add NAME package"
  9. Submit a pull request against rpm/develop and provide links to scratch builds

HOWTO: update a package

  1. git rm foo-old.gem
  2. Change the version in the spec, set "Release" to 1
  3. Follow the "test a package" section above until it builds for all targeted platforms and required SCL + non-SCL modes.
  4. Download the source file (e.g. the .gem) into the spec directory and run git annex add foo.gem
  5. Commit the changes
    1. git add -A
    2. git commit -m "Update NAME to VERSION"
  6. Submit a pull request against rpm/develop and provide links to scratch builds

How does this repo work?

This repo contains a directory per source package and some tito configuration
and state (under rel-eng/). Each source package directory contains a spec
file and patches under version control plus references to the source files
(i.e. gems or tarballs).

These references are managed using git-annex, a git extension for tracking
large binary blobs outside of the git repo itself. This means we can
reference source files directly on rubygems.org etc, or perhaps set up a kind
of lookaside cache in the future. For now, we use the special web remote
with URLs to all of our source files available on the web.

tito's git-annex support will automatically (lazily) fetch files and cache
them in your local git checkout as and when you build packages.

tito works in two key stages: tagging and releasing. For every RPM build, a
tag needs to be created with tito (i.e. tito tag --keep-version) and this
git tag is pushed to the central repository. tito helps by creating a
%changelog entry and tags in standard formats etc.

When a tag is present in the central repository for a version, tito lets you
build a SRPM and submit to koji, which builds the binary package (whereupon it
gets pulled into our yum repositories). This tagging strategy means we can
rebuild a package from any point in the repository's history, and since the
git-annex metadata is part of the tagged commit, even the binary content is
effectively under source control.

This repository is intended to be branched like Foreman releases, but until
core project packages are built from here too, it will follow a linear history
on the rpm/develop branch.

License

Spec files are generally based on Fedora spec files, which means that unless a
spec file contains an explicit license attribution within it, it is available
under the MIT license.

TODO / ideas

Instead of using KojiReleaser, we should use KojiGitReleaser so Koji checks
out this repo from git and runs make srpm, which could use tito to build
the SRPM. This has the nice benefit of not accepting random SRPMs as builds
in Koji, giving end to end safety + verification. The Makefile could be in a
common/ directory.

(1-1/2)