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... -- Steve McIntyre, Cambridge, UK. st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
signature.asc
Description: PGP signature
