On Mon, Jan 11, 2016 at 09:52:08AM +0100, Ansgar Burchardt wrote: > dak doesn't really like having a package in multiple components: the > layout of pool/ requires that the files would have to be duplicated. > Then dak only knows that a "binary package" belongs to a suite, not to > a given (suite, component) tuple, i.e. it will just appear in the > component where the files are located.
I don't understand why we're talking about duplicating the actual .deb-s here. What I'd have imagined---but I don't know the internals of dak, so there is only that much I can contribute to the design discussion---is that the .deb-s would have been in a single place; under non-free exactly where they are now. Then, in addition to the usual Packages files for non-free, we would generate *another* one, that APT can find under non-free/firmware, which only contains a given subset of the .deb-s. Now of course the question is how to tell the Packages generation part of dak which packages should be in that subset Packages file. I would've expected to use some metadata for that. "Section: non-free/firmware", suggested by pabs, seems reasonable enough. > I also think that it is nicer for packages to be just in one canonical > location. Absolutely agreed. > Finally note that users will most likely have to update their > sources.list for the stretch upgrade anyway as I also plan to rename > the security suite[1]. (It has been suggested to use symlinks to > allow continued use of the old names, but I think apt checks the > Suite: and Codename: fields of Release these days so that might not be > enough. We also might want to eventually drop the old name.) I don't think that the fact users have to update their sources.list anyhow for an unrelated change is a very solid argument for imposing another one onto them. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: PGP signature
