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 (k...@debian.org) <https://debamax.com/> > D-I release manager -- Release team member -- Freelance Consultant
