Difference between revisions of "Packaging"

From GalliumOS Wiki
Jump to: navigation, search
(Package Building)
Line 37: Line 37:
  
  
== Workflow (proposed) ==
+
== Development and Packaging Workflow (proposed) ==
  
 
Debian/Ubuntu has a fairly complex system for creating `deb` packages for use in `apt` repositories and distributions. There are many approaches and sets of tools to choose from.
 
Debian/Ubuntu has a fairly complex system for creating `deb` packages for use in `apt` repositories and distributions. There are many approaches and sets of tools to choose from.

Revision as of 20:08, 15 January 2016

For documentation and discussion. Design is still in flux.

Repositories and Distributions

We have one apt repository at https://apt.galliumos.org/ which serves three "distributions" (confusing name, but there it is).

The current distributions are:

  • vivid-galliumos ("release" or "stable")
    • contains fully released, production packages, and is the (only) default repodist for all users, installed by galliumos-base
    • priority pinned at 9999
      • trumps Canonical's vivid repodist for all package versions
      • trumps GalliumOS's vivid-galliumos-prerelease repodist only with newer versions
  • vivid-galliumos-prerelease ("prerelease", "staging", or "unstable")
    • contains prerelease packages (expected to be stable and ready for general use)
    • priority pinned at 9999
      • trumps Canonical's vivid repodist for all package versions
      • trumps GalliumOS's vivid-galliumos repodist only with newer versions
  • vivid-galliumos-testing ("testing", "experimental", "current", or "development")
    • contains testing packages (very possibly broken, not ready for general use)
    • priority pinned at 10090
      • trumps all other repodists (Canonical and GalliumOS) for all package versions

To enable or disable repodists

The galliumos-repodist script is included in the galliumos-base package.

Usage is straightforward:

  • galliumos-repodist --enable prerelease
  • galliumos-repodist --disable prerelease
  • galliumos-repodist --status

See galliumos-repodist --help for more.


Development and Packaging Workflow (proposed)

Debian/Ubuntu has a fairly complex system for creating `deb` packages for use in `apt` repositories and distributions. There are many approaches and sets of tools to choose from.

Development

All packages distributed by GalliumOS are maintained at https://github.org/GalliumOS.

GalliumOS Origin Packages

Code for GalliumOS origin packages (e.g. galliumos-base) is committed to the git repo as a regular project tree

  • We include a debian directory and associated config files for packaging

Upstream Origin Packages

Code for upstream origin packages is committed as an expanded copy of the upstream archive

  • If upstream is Ubuntu or Debian or Debian-via-Ubuntu
    • The tree will already include a debian directory tree
    • A debian/galliumos/upstream file is added containing the full URL of the upstream dsc file
  • If upstream is another source
    • We will create a debian directory tree
  • GalliumOS patches to the upstream tree go into debian/patches
  • When we move to a new upstream version
    • Upstream changes are applied directly onto the existing tree
    • Our patches are updated if necessary to apply against the updated tree
    • debian/galliumos/upstream is updated with the new URL of the upstream dsc file

All Packages

Development changes should be performed on git branches, to allow multiple or parallel development efforts

However, changes will not be included in nightly package updates unless they:

  • Are merged back to master
  • Add a new entry to debian/changelog with an updated version string
    • If changes are not final and release-ready, update version 3.2.1-4galliumos1 to, e.g.: 3.2.1-4galliumos1+dev1

Packaging (nightly builds)

Packages are built nightly by an automated process:

  1. Code for each repo is pulled from the GitHub master branch
  2. Packages (both binary and source) are built
    • WIP: Some source packages are presently skipped
      • Some because they require a copy of the upstream source package tar file
      • Some others because the manually-presented upstream is inconsistent with our current tree, which will require manual adjustment to our repo to fix
  3. Packages are signed with the contact@galliumos.org signing key
  4. Signed packages are pushed to apt.galliumos.org
  5. Signed packages are imported in to distribution vivid-galliumos-testing

Packaging (release builds)

When preparing packages for a formal GalliumOS release, the master branch of each active GitHub repository is tagged with the release label (e.g. 1.0beta2, 1.0, etc)

Package Versioning

Our package version naming convention descends from upstream Ubuntu packages, where applicable. Ubuntu's package versioning works like this:

Sample Package Version Strings

  • 3.2.1 Packages from original sources, without Debian or Canonical patches
  • 3.2.1-1 Packages patched by Debian (v1) but not Canonical
  • 3.2.1-0ubuntu1 Packages patched by Canonical (v1) but not Debian (Canonical adds the implicit zero)
  • 3.2.1-1ubuntu2 Packages patched by Debian (v1) and Canonical (v2)


GalliumOS Package Version Strings

Our version string might include a galliumosN tag (N=version), depending on the source of the packaged material:

  • Original to us e.g galliumos-base
    • 3.2.1, no tag needed
  • From original sources, not patched by us
    • 3.2.1, no changes; reuse the version from the original source
  • From original sources, and patched by us
    • 3.2.1 becomes 3.2.1-0galliumos1, add the implicit -0 first, if necessary!
  • From Debian or Canonical (patched or not), not patched by us
    • 3.2.1, no changes; reuse the upstream version string
    • 3.2.1-4
  • From Debian (patched or not), and patched by us
    • 3.2.1-4 becomes 3.2.1-4galliumos1, add our tag.
    • 3.2.1 becomes 3.2.1-0galliumos1, add the implicit -0 first, if necessary!
  • From Canonical (patched or not), and patched by us
    • 3.2.1 becomes 3.2.1-0galliumos1, add the implicit -0 first, if necessary!
  • From Canonical via Debian (patched or not), and patched by us
    • 3.2.1-0ubuntu1 becomes 3.2.1-0ubuntu1-galliumos1, just add a hyphen and our tag
    • 3.2.1-4ubuntu1 becomes 3.2.1-4ubuntu1-galliumos1

More Examples

package version vendor version patches?
3.2.1 3.2.1 (none)
3.2.1-4 3.2.1 Debian v4, Ubuntu, GalliumOS
3.2.1-0ubuntu5 3.2.1 Debian, Ubuntu v5, GalliumOS
3.2.1-0galliumos6 3.2.1 Debian, Ubuntu, GalliumOS v6
3.2.1-4ubuntu5 3.2.1 Debian v4, Ubuntu v5, GalliumOS
3.2.1-4galliumos6 3.2.1 Debian v4, Ubuntu, GalliumOS v6
3.2.1-4ubuntu5-galliumos6 3.2.1 Debian v4, Ubuntu v5, GalliumOS v6
0git20151003.be882ef2 (unversioned, git date.hash) (none)
0git20151003.be882ef2-galliumos6 (unversioned, git date.hash) GalliumOS v6
0.1~beta2-1git20150920.d7f95b5-galliumos6 0.1~beta2 (plus git date.hash) Debian v1, GalliumOS v6

The hyphenation rules are due to Debian's complicated sort logic. See below for a demonstration.

   # These version strings are Debian-ordered from oldest to newest
   #
   3.2.1
   3.2.1-0galliumos1
   3.2.1-1
   3.2.1-1galliumos1
   3.2.1-1ubuntu1
   3.2.1-1ubuntu2
   3.2.1-2galliumos1
   3.2.1-10
   3.2.1-10galliumos1
   3.2.1-1ubuntu1-galliumos1
   3.2.1-1ubuntu2-galliumos1
   3.2.1-1ubuntu2-galliumos2
   3.2.1-1ubuntu2-galliumos10
   3.2.1-1ubuntu10-galliumos1
   3.2.1.1
   
   # These do not sort as expected, and are visually ambiguous: do not use!
   3.2.1-0-galliumos1             ## DO NOT USE; ambiguous
   3.2.1-0-ubuntu1                ## DO NOT USE; ambiguous
   3.2.1-0-ubuntu0-galliumos1     ## DO NOT USE; ambiguous
   3.2.1-0-ubuntu1-galliumos1     ## DO NOT USE; ambiguous
   3.2.1-1-galliumos1             ## DO NOT USE; ambiguous
   3.2.1-10-galliumos1            ## DO NOT USE; ambiguous