Difference between revisions of "Packaging"

Revision as of 22:19, 14 December 2015

Current State of Packaging

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

We have a second apt repository at https://apt-dev.galliumos.org/ which will be retired.

The current distributions are:

vivid-galliumos

STABLE / RELEASE (default)

priority pinned at 9999, will trump Canonical's vivid repo for all package versions

vivid-galliumos-prerelease

prerelease / staging / unstable

priority pinned at 10050, will also trump our vivid-galliumos repo for all package versions

vivid-galliumos-testing

testing / experimental / current / development / etc

priority pinned at 10090, will also trump our vivid-galliumos-prerelease repo for all package versions

General users will only have our vivid-galliumos distribution enabled (and Canonical's vivid distribution, of course).

Packages

Our package version naming convention descends from upstream Ubuntu packages, where applicable.

e.g. for packagename (1.2.3-0ubuntu1), our patches should be packaged as packagename (1.2.3-0ubuntu1-galliumos1). Some upstream packages will not have an -ubuntuX suffix, which means that they are unchanged from the Debian up-upstream. We still need to add our -galliumosX suffix.

Package Version Discrepancies!

We have some existing packages which do not follow this naming convention, and are versioned ahead of their upstreams (e.g. 1.2.3 in upstream to our 1.2.4). This causes a few issues:

1. It's confusing for us and gives users the impression that our code is a release ahead of the upstream.
2. When the upstream releases a 1.2.4, it will have different code than our 1.2.4.
3. debootstrap builds will fail to update to our pkgs when version numbers collide.

Package Version Corrections!

There are a couple ways to fix this issue:

1. Make a hard break sometime between current (BETA1) and 1.0 (simple, guaranteed to work)
   • Update packages with corrected version numbers, existing systems will not update to new packages.
   • All users have to reinstall to move forward. :(
2. Add a new "pkgversionfix" repodist, via inclusion in a required package (more complex, needs testing)
   • This could be done to require no user intervention (aside from the standard `apt-get` process)
   • Populate new repodist with corrected packages, populate primary (stable) repodist with corrected packages+1. Force a "downgrade" via "pkgversionfix" repodist to the corrected packages, then disable the new repodist. This could be done with a few manual steps, or automated by a startup script (or maybe a pkg postinstall script?). Automated is more user-friendly, but might be surprising.
3. Create a manual update script (simpler, less surprising)
   • Similar to option 2, but requires user intervention (e.g. running a galliumos-update-system script).
4. Hardwire version dependencies in existing galliumos-star packages (and maintain them!)
   • For an indeterminate length of time...until substantially all users have updated.

Scripted process for option 2 (and possibly option 3) would look something like this:

 ## add new pkgversionfix repodist
 apt-get install galliumos-distselect-pkgversionfix
 
 ## "downgrade" packages
 apt-get update && apt-get -y --force-yes dist-upgrade
 
 ## Remove new repodist
 apt-get purge galliumos-distselect-pkgversionfix
 
 ## Get corrected+1 pkgs from the main repo
 apt-get udpate && apt-get dist-upgrade

This needs testing, but I think it will work. Any better ideas?

Deviant package versions

These packages are currently problematically versioned: