Re: Going ahead with non-free-firmware
Stefano Zacchiroli <zack@debian.org> writes:
> On Sat, Jan 09, 2016 at 08:48:25PM +0000, Steve McIntyre wrote:
>> Are we sure on the name? Previous commenters have suggested that
>> "non-free/firmware" might be better. I understand that may be more
>> awkward to implement in terms of directories... :-)
>
> If my recalling is correct, at the BoF there was indeed a mild
> preference for non-free/firmware, because that names better captures the
> fact that /firmware is indeed a sub-part of "non-free" rather than
> something new.
And gives problems: the "Section" field has either just the ${section}
or ${component}/${section}. If component now also has a "/" in it,
there will likely be bugs. I don't think aesthetic reasons call for
this breakage if we can avoid it.
> There was also concerns that introducing something
> *separate* wouldn't fly with the social contract, which explicitly
> mentions main/contrib/non-free whereas it does *not* mention
> non-free-firmware. In that sense "just" allowing to select a sub part of
> non-free wouldn't be a problem, whereas introducing something new might
> be.
If the social contract would forbid creating a new section
"non-free-firmware", I don't think that changing a letter in the name
would change much.
> But an important part of the above reasoning in favor of
> non-free/firmware was that user enabling explicitly non-free in the
> sources.list and *not* enabling non-free/firmware would get the non-free
> firmware anyhow. I.e., no regressions or changes needed w.r.t. the
> status quo. From other messages in this thread I understand this is
> actually not going to be the case. Which would be problematic and also a
> little bit disturbing. Is really no technical way to easily allow to
> have packages in multiple (sub-)parts of the archive?
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.
Now one could hack dak into duplicating files intentionally for some
uploads, but I don't really like that: it allows disparities between the
packages in "non-free" and "non-free-firmware" as some settings are
applied per-suite (e.g. copying packages to testing) and others
per-component (e.g. overrides) and some are implicit on where files are
located. The latter because originally files could only be located in
one component, but this caused issues when packages moved between
components and reused the same upstream tarball.
I also think that it is nicer for packages to be just in one canonical
location.
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.)
Ansgar
[1] <https://lists.debian.org/debian-security/2015/12/msg00015.html>
Reply to: