Research what solution to use for the freezable APT repository
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 to Tails -
#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
> * 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.