summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/freezable_APT_repository.mdwn
diff options
context:
space:
mode:
authorintrigeri <intrigeri@boum.org>2016-05-18 17:29:22 +0000
committerintrigeri <intrigeri@boum.org>2016-05-18 17:29:22 +0000
commit35fab3b5a7685133fafa22e8a34837282a444d8f (patch)
tree9e9bb07a1ad35b5616c5cdc3a9daeb16c11db614 /wiki/src/blueprint/freezable_APT_repository.mdwn
parent85eeba13397f140cfa103c72ce19baa2d5bafb25 (diff)
Remove stuff that was imported in the freezable APT repo design doc.
Diffstat (limited to 'wiki/src/blueprint/freezable_APT_repository.mdwn')
-rw-r--r--wiki/src/blueprint/freezable_APT_repository.mdwn123
1 files changed, 0 insertions, 123 deletions
diff --git a/wiki/src/blueprint/freezable_APT_repository.mdwn b/wiki/src/blueprint/freezable_APT_repository.mdwn
index a3c874a..7a8226a 100644
--- a/wiki/src/blueprint/freezable_APT_repository.mdwn
+++ b/wiki/src/blueprint/freezable_APT_repository.mdwn
@@ -2,24 +2,6 @@ This is about [[!tails_ticket 5926]].
[[!toc levels=3]]
-# Assumptions
-
-A given APT repository snapshot is immutable after it's been taken.
-We'll deal with freeze exception separately.
-
-We want to have reproducible builds some day. Therefore, the APT
-`sources.list` shipped in the ISO must be stable across rebuilds from
-the same release Git tag.
-
-Say `kedit` is a package shipped in Debian, but not in Tails. Then,
-when run inside Tails, `apt install kedit` must fetch `kedit` from
-current Debian, as opposed to installing it from a Tails-specific, and
-generally obsolete, snapshot of the Debian APT repository.
-
-We don't bother merging mirrored APT repositories / suites into
-aggregated ones. It loses information, gives us more work, and brings
-little value.
-
<a id="todo"></a>
# TODO
@@ -60,113 +42,8 @@ little value.
* implement whatever the "freeze exceptions" section requires
([[!tails_ticket 11446]], [[!tails_ticket 11448]])
-# The big picture
-
-## Snapshots and branches
-
-Building an ISO from the `devel` branch always uses the freshest set
-of APT repository snapshots available. Resolving what's the set of
-freshest APT repository snapshots is done at the beginning of the
-build ([[!tails_gitweb auto/config]],
-[[!tails_gitweb auto/scripts/apt-mirror]]), so that the entire build
-uses the exact same state of these
-repositories. This is needed for reproducible builds, and has a nice
-side effect: so long, `Hashsum mismatch`, and thanks for the fish.
-
-When building an ISO from the branch used to prepare the next major release
-(`testing`), or a topic branch based on it (`config/base_branch`):
-
- * **outside of the freeze period**: we use the latest set of APT
- repository snapshots, just like when building from `devel`;
- * **freeze period**: at freeze time, the RM encodes in the Git
- `testing` branch the set of APT repository snapshots (via their
- serial numbers) that shall be used during the freeze; the only
- exception is security.debian.org, for which we always use our
- latest snapshot;
- * **at release time**: when building from a tagged branch, similarly to
- what we do for our custom [[contribute/APT_repository]], instead of
- using time-based APT repository snapshots, we use snapshots
- labeled with the Git tag (note that this is not needed, strictly speaking,
- as the APT sources used at Tails runtime will anyway be the
- official (and not frozen) Debian ones; this is mostly needed for
- legal purposes (this allows to distribute for a long
- time the source packages needed to build a given Tails ISO image),
- and it will be useful when we want to be able to reproduce a given
- Tails ISO build);
- * **after releasing**, the RM encodes in the `testing` Git branch the
- fact that it is not frozen anymore, that is: the RM removes the
- indication that a specific set of APT repository snapshots must be
- used; and then, we're back to the "outside of the freeze
- period" case.
-
-When building an ISO from the branch used to prepare the next point-release
-(`stable`), or a topic branch based on it (`config/base_branch`
-contains `stable`), we
-use snapshots labeled with the Git tag of the latest Tails release,
-except:
-
- * we generally use our latest snapshot of security.debian.org;
- * at release time: when building from a tagged branch, similarly to
- what we do for our custom [[contribute/APT_repository]], instead of
- using time-based APT repository snapshots, we use snapshots
- labeled with the Git tag
- * if a set of APT repository snapshots is encoded directly in that
- branch: use them, even for security.debian.org.
-
# Special cases and implementation
-## Custom APT repository
-
-Our custom APT repository (<http://deb.tails.boum.org/>) is not part of
-the first iteration of this system: it's not needed, since we already
-have a process to manage it, including creating snapshots labeled with
-the Git tag.
-
-However, longer-term, ideally we would integrate it into the new
-system. It will require quite some infrastructure and code, if we want
-to avoid making the release process more painful (e.g. it would be nice
-if this didn't require waiting up to 6 hours until the next time-based
-snapshot of our custom APT repository is created, between the time we
-upload a package to it, and when we can build an ISO with it; we could
-solve this by automatically creating a new snapshot whenever an APT
-suite corresponding to a release branch is updated).
-
-<a id="runtime-sources"></a>
-
-## APT sources used inside Tails
-
-A running Tails' APT must be pointed at the official, live Debian
-archive, and not to a Tails-specific and already obsolete snapshot.
-
-To achieve that we tweak `sources.list` in
-[[!tails_gitweb config/chroot_local-includes/lib/live/config/1500-reconfigure-APT]].
-
-## Upgrading to a new snapshot
-
-In other words: bumping, in Git, the pointers to the set of snapshots
-that shall be used.
-
-Let's use, as an example of a situation in which we might want to do
-that, upgrading to a new Debian point-release.
-
-With this design:
-
- * `devel` gets them automatically because it closely tracks the
- Debian archive;
- * for release branches (`stable`, `testing`): on a case-by-case
- basis, depending on the respective Debian/Tails release schedule
- timing, we can choose whether to switch to using a new snapshot of
- the Debian archive for the next release. Note that this can be done
- via a topic-branch since this information is encoded in Git. If we
- choose not to manually pick the point release, which is the default
- if we don't act at all, then:
- - `testing` will start using the new Debian point-release as soon
- as it is unfrozen, that is as soon as it has been used to release
- a new major version of Tails;
- - `stable` will start using the new Debian point-release once
- a `testing` branch that uses that point-release is merged into
- `stable`.
-
<a id="freeze-exceptions"></a>
## Freeze exceptions