How Emdebian makes a release, using reprepro

reprepro now has a "read-only" mode for a genuinely frozen distribution - used by adding ReadOnly:yes in conf/distributions. The previous advice here had problems with trying to overlay the frozen pool/ directory and has been superceded by ReadOnly:yes.

If ReadOnly:yes is not set, stable is created within the existing repository, every action to include new or updated packages in the repository or modify repository data, causes the Release files for the stable distribution to be touched. This should not happen and it breaks the security signatures on the Release files. Once ReadOnly:yes is set, the read-only distribution is ignored by general repository updates and reprepro gives an error if you attempt to alter the read-only distribution explicitly.

Whilst checking your repository prior to the release, ensure that your configuration has suite and codename the right way around. suites can change, codenames must be pulled - i.e. reprepro can change a suite (unstable, testing, stable, oldstable) during a normal export but changing a codename (etch, lenny, squeeze, sid) can only be done by creating the codename you need and pulling packages from the old codename to the new.

Do NOT get suites and codenames confused!

Your dists directory should contain something like:

lenny
lenny-proposed-updates
sid
squeeze
stable -> lenny
stable-proposed-updates -> lenny-proposed-updates
testing -> squeeze
unstable -> sid

This arises from having a conf/distributions file containing:

Suite: unstable
Codename: sid

The Codename exists as a real directory, the Suite is the symlink. (This is because when a release is made, the symlink is moved, not the release. stable changes from pointing at etch to pointing at lenny etc.)

Making a full release is then a case of modifying the conf/distributions file, pulling testing into stable and reinstating the ReadOnly:yes flag in conf/distributions. Remember to make all alterations to the stable stanza of conf/distributions only after unsetting the ReadOnly:yes flag to no or commenting out the entire line. If you've used testing-proposed-updates, you will also need to pull from there after pulling from testing. Once the release is complete, reinstate the ReadOnly:yes protection before making the release announcement.

Making a point release involves a similar process but pulling from stable-proposed-updates.

First Edits for conf/distributions

Increment the Version for each stanza in conf/distributions
Add the relevant Pull: option to the stable stanza to update stable from testing
Add the relevant Pull: option to the oldstable stanza to update oldstable from stable
Remove the oldstable stanza and copy the stable stanza to oldstable
Toggle the ReadOnly:yes flag for stable to no or comment out that line
Toggle the ReadOnly:yes flag for oldstable to no or comment out that line

pull stable into oldstable

(Make sure you do this before pulling testing into stable.

$ reprepro -b /path/ -v export
$ reprepro -b /path/ -v checkpull oldstable
$ reprepro -b /path/ -v pull oldstable

This stage can be done some time before the release - in Debian it may be done as much as a week before the actual change to stable. Therefore, for a short period, oldstable and stable are the same. If you do update oldstable some time before doing the stable release, reinstate the ReadOnly:yes flag on oldstable and stable once the first pull is complete and disable ReadOnly:yes on stable again just before the actual stable release.

pull testing into stable

Do all the checks you can before getting to this point.

$ reprepro -b /path/ -v export
$ reprepro -b /path/ -v checkpull stable
$ reprepro -b /path/ -v pull stable

The release is now live but the new testing distribution does not yet exist.

Second Edits for conf/distributions

Change the testing stanza to describe stable
Add the new Codename for the new testing stanza
Toggle the ReadOnly:no flag for stable to yes or uncomment that line
Toggle the ReadOnly:no flag for oldstable to yes or uncomment that line

update the repository structure

$ reprepro -b /path/ -v export
$ reprepro -b /path/ -v createsymlinks

Sample local test for apt

deb file:///opt/reprepro/grip/ lenny main

Sample apt-cache policy output:

$ apt-cache policyPackage files:
 100 /var/lib/dpkg/status
     release a=now
 500 file: lenny/main Packages
     release v=0.1,o=Debian,a=stable,l=EmdebianGrip,c=main
 500 http://www.emdebian.org unstable/main Packages
     release v=0.1,o=Debian,a=unstable,l=Emdebian-tools-unstable,c=main
     origin www.emdebian.org
 500 ftp://ftp.fr.debian.org unstable/main Packages
     release o=Debian,a=unstable,l=Debian,c=main
     origin ftp.fr.debian.org
Pinned packages:

For a specific test package:

$ apt-cache policy zlib1g
zlib1g:
  Installed: 1:1.2.3.3.dfsg-12
  Candidate: 1:1.2.3.3.dfsg-12em1
  Version table:
     1:1.2.3.3.dfsg-12em1 0
        500 file: lenny/main Packages
 *** 1:1.2.3.3.dfsg-12 0
        500 ftp://ftp.fr.debian.org unstable/main Packages
        100 /var/lib/dpkg/status