Re: Changing how we handle non-free firmware
On 2022-08-30 21:57:56, Steve McIntyre wrote:
> On Tue, Aug 30, 2022 at 04:27:17PM -0400, Antoine Beaupré wrote:
>>On 2022-08-30 21:11:07, Steve McIntyre wrote:
>>>
>>> But I want to be *very* clear here that we *don't* want to enable the
>>> whole of the non-free component for all users by default. That would
>>> be a grave disservice, and I think Ansgar agrees with me. There's no
>>> need to hold this back to be part of the GR here IMHO.
>>
>>Yeah, so I think that's a great advantage of splitting firmware out of
>>non-free: it keeps the "non-free blast radius" to a minimum, just to
>>make sure people can get their hardware working without getting all that
>>other stuff that they should really opt into.
>>
>>Yet I actually use non-free for other stuff as well, at a personal
>>level. Things like documentation, for example, often end up in non-free
>>for $reasons and I have non-free enabled for *both* this and firmware.
>>
>>In that sense, why wasn't it possible to have (say) non-free/firmware as
>>a component, so that when you opt-in to non-free you *also* get
>>firmware? That would have been a backwards-compatible change...
>
> I genuinely am not sure how various tools will interact with that kind
> of change to have nested components, tbh. I'd rather be clean and
> consistent here, and I believe Ansgar agrees. Similarly that's why the
> new non-free-firmware component has no special handling to try and and
> override package uploads there. Special cases suck, particularly
> as/when/if they stack on top of each other...
Didn't we have buster/updates for a while? Is breakage related to that
the reason why we're not doing this here?
--
The United States is a nation of laws:
badly written and randomly enforced.
- Frank Zappa
Reply to: