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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)