Stefano Zacchiroli <z...@debian.org> writes:
> 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.
So you don't want another component, but something that looks like a
component in some places only? I.e. it behaves like a component in that
it gets its own Packages (and Sources?) indices, but it has neither its
own area in pool/ nor is it used in packages' Section field.
I really don't want to add new special cases to dak, but get rid of
them. They often don't work that well and get even less testing than
other parts of dak: as an example the fact that components are not named
{main,contrib,non-free}, but updates/{main,contrib,non-free} on the
security archive causes breakage quite often when related code is
changed... (This is one of my motivations behind changing the security
archive besides the confusion about */updates vs *-updates.)
So I really don't want to implement support for this and have to
maintain it if it can be avoided.
>> 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.
I don't think it's particular bad to have to update sources.list either:
we often required so already (*-volatile, *-updates come to mind). Its
nice to not have to think of this when updating machines, but I don't
think it warrants avoiding at all costs either.
Ansgar
