Re: Bug#1029848: hw-detect: decide how to configure firmware support
On Sat, Jan 28, 2023 at 08:09:58PM +0100, Cyril Brulebois wrote:
> Package: hw-detect
> Severity: important
>
> Hi,
>
>
> # Allowing for main-only
>
> The next sentence of the text that was agreed to is:
>
> The included firmware binaries will normally be enabled by default
> where the system determines that they are required, but where
> possible we will include ways for users to disable this at boot
> (boot menu option, kernel command line etc.).
>
> I'd like us to determine the following things:
> - the best name for an internal-only template for hw-detect;
> - the best alias for it, to be used e.g. on the Linux command line, to
> save some typing;
> - what values it should support;
> - what semantics should be attached to those values.
>
hwdet or hwdfrm as the name of the template / command line alias
It is relatively short, doesn't include a hyphen and is unlikely to overlap
with another utility.
> on supporting maybe fewer things, but supporting them well.
>
> hw-detect already has a loop, the concept of searching for firmware on
> external media, the concept of asking, etc.
>
> It really doesn't make sense to me to have any kind of per-file,
> per-module, or per-package granularity. This would mean many prompts,
> possibly with way too many lines (see how many files iwlwifi can
> request), and wouldn't really help users make an informed decision.
> Extra templates would also mean more work for translators…
>
> Therefore, my current approach would be not to try and implement some
> yes/ask/no trichoice as originally envisioned, but to provide users
> wanting to avoid firmware altogether a way to do so.
>
>
> I'm proposing:
> - “hw-detect/firmware” as template for hw-detect;
> - “firmware” or “fw” as an alias for shorter typing (“fw” feels like
> extremely short);
fw would make me think of firewalls (although I do appreciate fwupd is
now established).
> - “never” value to skip firmware handling altogether, meaning skipping
> both mechanisms mentioned above.
>
> That would leave us a rather important flexibility regarding other
> behaviours that we might want to implement, depending on the use cases
> that might get identified (#1029543), without having to make a decision
> about those (names and associated semantic) right now.
>
> Implementing this (and documenting it in the installation guide) would
> make us comply with what was agreed to.
>
>
> Swift feedback would be appreciated, thanks!
>
Thank you very much indeed for all the hard work the rest of us can see is
going on.
Andy Cater
>
> Cheers,
> --
> Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
> D-I release manager -- Release team member -- Freelance Consultant
Reply to: