Differences between revisions 5 and 6
Revision 5 as of 2009-02-14 19:54:34
Size: 1923
Editor: NeilWilliams
Comment:
Revision 6 as of 2009-02-14 20:01:28
Size: 2442
Editor: NeilWilliams
Comment:
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
The problem is that if 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. The problem is that if 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.
Line 8: Line 8:

The important point in this process is that '''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 [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515114 suites and codenames] confused!
Line 32: Line 36:
Add squeeze (testing) in old repo conf/distributions

How Emdebian makes a release, using reprepro

reprepro will gain a [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515030 "read-only" mode] for a genuinely frozen distribution, but a few workarounds are necessary with the current version of reprepro.

The problem is that if 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.

The solution is to put stable into a second repository, all by itself, clearly identified as 'frozen' and then symlink that directory so that apt and similar tools can find it where they expect to find it. Naturally, this means removing stable from the existing repository.

The important point in this process is that 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 [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515114 suites and codenames] confused!

Emdebian Release Plan

Create a frozen directory.
Copy conf/distributions into frozen/conf and delete all lines for unstable.
Rename testing as stable and remove any existing update and override rules.
Generate data for lenny (stable).
reprepro -b frozen/ export
reprepro -b frozen/ createsymlinks
Create an updates file in frozen/conf
Name: freeze
Method: file://opt/reprepro/grip/
Suite: testing
Add updates file to frozen/conf/distributions
Update: freeze
Update frozen from lenny (testing) in current repository.
reprepro -b frozen/ checkupdate
reprepro -b frozen/ update
Remove update rule from frozen/conf/distributions
Remove update file from frozen/conf/
        we now have a frozen lenny (stable)
Delete testing/ symlink in old repo
Change lenny in old repo to stable in conf/distributions
Add squeeze (testing) in old repo conf/distributions
reprepro export
reprepro createsymlinks
Pull lenny (testing) in old repo into new squeeze (testing)
Remove lenny from old repo conf/distributions
rm -rf dists/lenny
reprepro --delete clearvanished


CategoryEmdebian