Feature #9487

Research what solution to use for the freezable APT repository

Added by intrigeri 2015-05-28 15:24:49 . Updated 2016-03-25 22:17:18 .

Target version:
Start date:
Due date:
% Done:


Feature Branch:
Type of work:

Affected tool:
Deliverable for:


The first step is to specify when we want to import foreign packages into which suites, propose something and lead this discussion to a conclusion. Then we can evaluate if we can use reprepro, have a look at aptly and at what other are doing it.


Feature #6295: Evaluate consequences of importing large amounts of packages into reprepro Resolved


Feature #7427: Evaluate using aptly Resolved


Feature #6906: Ask the Grml people how they handle the "keep lots of source packages around" problem Resolved


Feature #9488: Specify how we want to sync packages from Debian Resolved


Related issues

Related to Tails - Feature #9508: Evaluate freezable APT repo's storage needs Resolved 2015-05-30


#1 Updated by intrigeri 2015-05-28 15:25:04

  • blocks #8668 added

#2 Updated by intrigeri 2015-05-28 15:33:20

  • Description updated

#4 Updated by intrigeri 2015-05-28 15:46:04

  • Target version changed from Tails_2.3 to 246

#5 Updated by intrigeri 2015-05-30 13:42:20

  • related to Feature #9508: Evaluate freezable APT repo's storage needs added

#6 Updated by intrigeri 2015-05-30 19:03:22

Kali’s solution seems to be more appropriate for a rolling distro (based on Debian testing) and a bit too heavyweight for our use case.

Tanglu’s solution is powered by rapidumo, aka. “Tanglu Archive Tools Collection Tools and services to handle the Tanglu archive, working together with dak and Debile/Jenkins”. It indeed wraps a lot of stuff that mostly makes sense for a non-Live distro that manages a full fork of the Debian archive, rebuilds packages, etc. (many things we don’t do).

=> My current opinion on this topic is that both Kali’s and Tanglu’s solutions are not what we need, and using them would take a lot of time.

#7 Updated by intrigeri 2015-05-31 08:34:03

intrigeri wrote:
> * Kali (reprepro + britney for co-installability):

Update: Kali indeed uses a slightly patched britney, plus a nice Python script+lib that translates britney’s heidi results into calls to reprepro (I now have that code, not sure if I can publish it). In practice, co-installability checks would mostly (only?) be useful to us when we’re frozen and we pull some selected package update into our current snapshot of the Debian archive. Such updates will in most cases come from the security archive, or from stable updates / proposed-updates, and should cause no co-installability problems. Also, even if there were co-installability problems:

  • for packages shipped in Tails, we would notice at ISO build time;
  • for additional packages installed by users, oh well, we’re already introducing such problems ourselves with our APT pinning anyway.

=> I still think we should not bother about it.

#8 Updated by intrigeri 2015-06-06 09:11:29

It would be good to also have a look at Whonix build system, that can use http://snapshot.debian.org's APT sources.

#9 Updated by intrigeri 2015-08-26 06:00:19

  • Deliverable for set to 269

#10 Updated by intrigeri 2015-11-02 02:39:40

  • Status changed from Confirmed to In Progress
  • Target version changed from 246 to Tails_1.8

#11 Updated by intrigeri 2015-12-13 05:47:19

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

#12 Updated by intrigeri 2016-01-26 12:13:25

  • Target version changed from Tails_2.0 to Tails_2.2

#13 Updated by intrigeri 2016-03-03 20:16:11

  • Target version changed from Tails_2.2 to Tails_2.3

(Like the remaining subtask, a conclusion will be reached in 3 weeks.)

#14 Updated by intrigeri 2016-03-25 22:16:59

  • blocked by deleted (#8668)

#15 Updated by intrigeri 2016-03-25 22:17:18

  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)

We’re done here.