diff options
authorintrigeri <>2016-05-21 14:53:35 +0000
committerintrigeri <>2016-05-21 15:00:55 +0000
commitdcae3839d61ad56d87c530910bf22f2b5949cdb0 (patch)
parent38fb2ddfeefab68f80ba0f9e892ba879069a86d9 (diff)
APT freeze exceptions: draft updated design.
... and add placeholders wherever we need to document more hands-on steps.
2 files changed, 79 insertions, 0 deletions
diff --git a/wiki/src/contribute/APT_repository/time-based_snapshots.mdwn b/wiki/src/contribute/APT_repository/time-based_snapshots.mdwn
index dea2e01..6838fbe 100644
--- a/wiki/src/contribute/APT_repository/time-based_snapshots.mdwn
+++ b/wiki/src/contribute/APT_repository/time-based_snapshots.mdwn
@@ -158,6 +158,11 @@ For example, when we stopped tracking Wheezy, we did:
| xargs -n 1 reprepro _removereferences \
&& reprepro deleteunreferenced
+Freeze exception
# Design notes
## gensnapshot
@@ -312,3 +317,76 @@ situation here is mostly:
possible, but also reasonably easy to handle with this design
(otherwise we may have to switch to more powerful tools, such as
dak + britney).
+To grant a freeze exception to a given package, we simply import it
+into our own
+[[custom APT repository|contribute/APT repository/custom]], in the
+suite corresponding to the branch that we want to see this package ⇒
+in the general case, the upgraded package will be installed in the
+next Tails release.
+This works because our APT pinning ranks Tails custom APT suites at
+the same level as the other APT sources corresponding to the current
+version of Debian Tails is based on, and higher than other Debian
+distribution (which, in passing, implies that we have to manually pin,
+in Git, the packages from our custom APT suites, that we want to
+override the ones found in other repositories regardless of version
+ * if the imported package comes from Debian stable: it will be
+ installed simply because its version is greater than the version of
+ the same package from Debian stable; and once we have thawed the
+ corresponding snapshot, the package can be pulled equally from any
+ of these two sources (Debian, and our custom APT repository), until
+ a newer version of this package is uploaded to Debian, and then the
+ newer one will supersede the package we have in our custom APT
+ repository;
+ * if the imported package comes from another Debian distribution,
+ that has a pinning value strictly lower than 990, such as Debian
+ unstable: if we did nothing more, the package would be installed
+ because its pinning (`origin`) is higher than
+ the one from the Debian distribution we're importing it from;
+ *however*, in this case we need to track this package, and to
+ remove it from our custom repository after we have thawed the
+ corresponding snapshot — otherwise, due to this pinning
+ configuration, we would stick to the version of the package we have
+ one day imported, while in most cases we want to resume tracking
+ the version from Debian; so, we do this that way:
+ 1. Import the package we want to upgrade into our own
+ [[custom APT repository|contribute/APT repository/custom]], in
+ the suite corresponding to the branch that we want to see this
+ package.
+ 2. Explicitly pin, in `config/chroot_apt/preferences`, the upgraded
+ package we have just imported to a value higher than 990, with
+ a proper `Explanation:` field; this pinning is not required at
+ this stage, but it is one way to encode in Git the packages we
+ have imported, which simplifies the following (clean up) step.
+ 3. Once the corresponding APT snapshot has been thawed, that is
+ once the upgraded package can be fetched from a newer time-based
+ snapshot of the repository we've initially pulled it from: make
+ it so branches stop using the upgraded package, and resume
+ tracking the one available in Debian. To do that, we modify the
+ pinning entry added at the previous step, and give it a value of
+ `-1`. This should be done by the release manager, immediately
+ after a release, when they thaw the APT snapshots used for the
+ release, and merge it into other release branches.
+ Ideas for future improvements:
+ * At some point a helper tool can do this automatically,
+ assuming we always use the same `Explanation:` field to mark
+ these pinning entries. (Ideally we would simply use
+ a dedicated file under `apt/preferences.d/` for freeze
+ exceptions, but `live-build` 2.x doesn't support that.)
+ * Ideally we would remove these imported packages from our
+ custom APT repository at post-release time as well, so we can
+ get rid of the `-1` pinning entries, but it really needs to be
+ done in a 100% correct order, to ensure that after all the
+ merges we do post-release (and sometimes at other times)
+ between release branches, the imported packages are _not_
+ present anymore in any of the corresponding APT suites.
diff --git a/wiki/src/contribute/release_process.mdwn b/wiki/src/contribute/release_process.mdwn
index f7c6469..88b0cd0 100644
--- a/wiki/src/contribute/release_process.mdwn
+++ b/wiki/src/contribute/release_process.mdwn
@@ -1100,6 +1100,7 @@ this, and skip what does not make sense for a RC.
for an emergency release that was never made.
1. [[Thaw|APT_repository/time-based snapshots#thaw]] the time-based
APT repository snapshots that were used during the freeze, if any.
+1. XXX: update pinning for freeze exceptions
1. Pull `master` back and merge it into `stable`, and in turn into
1. Follow the