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:220.127.116.11.dfsg-12 Candidate: 1:18.104.22.168.dfsg-12em1 Version table: 1:22.214.171.124.dfsg-12em1 0 500 file: lenny/main Packages *** 1:126.96.36.199.dfsg-12 0 500 ftp://ftp.fr.debian.org unstable/main Packages 100 /var/lib/dpkg/status