Feature #9488

Specify how we want to sync packages from Debian

Added by intrigeri 2015-05-28 15:35:22 . Updated 2016-03-25 22:16:27 .

Status:
Resolved
Priority:
High
Assignee:
Category:
Infrastructure
Target version:
Start date:
2015-05-28
Due date:
% Done:

100%

Feature Branch:
Type of work:
Research
Starter:
Affected tool:
Deliverable for:
269

Description

More specifically: which packages? when? into which APT suite(s)? Think about it, come up with a proposal, discuss this with the community, lead this discussion to a conclusion.


Subtasks


History

#1 Updated by intrigeri 2015-05-28 15:38:09

  • blocks #8668 added

#2 Updated by intrigeri 2015-05-28 15:47:45

  • Target version changed from 246 to Tails_1.8

#3 Updated by intrigeri 2015-05-28 15:49:02

  • Priority changed from Elevated to Normal

#4 Updated by intrigeri 2015-05-30 19:15:57

On Feature #9508#note-1, I’ve added estimates of how much disk space various solutions would eat. This lead me to think a bit about importing selected packages only vs. importing entire APT dists, and my current take on this is that the latter is much more attractive a solution. In general, in wouldn’t make much difference, but there are use cases in which the latter solution makes the workflow trivial, while the other makes it hard to deal with: e.g. say I’m working on a topic branch that installs additional Debian packages; if we’re importing entire APT dists, then regardless of which stage of Tails development we are in (frozen or not), then it’ll just work since the newly needed package is already part of the mirror we’re using; OTOH, if we’re importing only the packages we think we need, then working on such a topic branch requires either that I have the credentials to import new packages from Debian into our own mirror (which raises the barrier for contributing), or that during some phases of Tails development the regular Debian archive is used instead of our own mirror (which makes it harder 1. to reason about when to freeze our own mirror, when working on this ticket; 2. to understand in which exact situation I can do what I want to, or not, when working on a topic branch). A policy of “no new packages added except on branches forked off devel” would solve this, and seems nice in theory, but I doubt it’ll work in practice, as there are probably cases when a bugfix branch that targets stable or testing needs to pull new packages, for some reason.

#5 Updated by intrigeri 2015-08-26 06:00:28

  • Deliverable for set to 269

#6 Updated by intrigeri 2015-10-22 09:39:39

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10
  • Blueprint set to https://tails.boum.org/blueprint/freezable_APT_repository/

An initial description of the problem, available options, and chosen design can be found on the blueprint.

#7 Updated by intrigeri 2015-12-13 05:47:15

  • Target version changed from Tails_1.8 to Tails_2.0

#8 Updated by intrigeri 2015-12-13 12:22:41

  • Priority changed from Normal to Elevated

I should submit our proposal to Tails developers soonish, so that we have time to address any fundamental design issues they might point us to.

#9 Updated by intrigeri 2016-01-26 12:12:24

  • Priority changed from Elevated to High
  • Target version changed from Tails_2.0 to Tails_2.2

#10 Updated by intrigeri 2016-03-03 20:13:40

  • Target version changed from Tails_2.2 to Tails_2.3
  • % Done changed from 10 to 50

#11 Updated by intrigeri 2016-03-04 10:58:28

  • Assignee changed from intrigeri to anonym
  • QA Check set to Ready for QA

#12 Updated by intrigeri 2016-03-25 22:16:27

  • Status changed from In Progress to Resolved
  • Assignee deleted (anonym)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

intrigeri wrote:
> * Sent a RFC to tails-dev@: https://mailman.boum.org/pipermail/tails-dev/2016-March/010369.html => I’ll consider the design validated if no blocker is found by March 23.

There we go!

#13 Updated by intrigeri 2016-03-25 22:16:43

  • blocked by deleted (#8668)