Project

General

Profile

Feature #9487

Feature #5926: Freezable APT repository

Research what solution to use for the freezable APT repository

Added by intrigeri over 4 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
High
Assignee:
-
Category:
Infrastructure
Target version:
Start date:
09/26/2013
Due date:
% Done:

100%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

Description

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.


Subtasks

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

Feature #7427: Evaluate using aptlyResolved

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

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


Related issues

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

History

#2 Updated by intrigeri over 4 years ago

  • Description updated (diff)

#4 Updated by intrigeri over 4 years ago

  • Target version changed from Tails_2.3 to 246

#5 Updated by intrigeri over 4 years ago

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

#6 Updated by intrigeri over 4 years ago

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 over 4 years ago

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 over 4 years ago

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

#10 Updated by intrigeri almost 4 years ago

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

#11 Updated by intrigeri almost 4 years ago

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

#12 Updated by intrigeri over 3 years ago

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

#13 Updated by intrigeri over 3 years ago

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

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

#15 Updated by intrigeri over 3 years ago

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

We're done here.

Also available in: Atom PDF