Hey kibi! On Sat, Jan 28, 2023 at 08:09:58PM +0100, Cyril Brulebois wrote: >Package: hw-detect >Severity: important > >Hi, > > ># Context > >Quoting the text that was agreed to via the 2022 General Resolution >about non-free firmware: > > We will include non-free firmware packages from the "non-free-firmware" > section of the Debian archive on our official media (installer images > and live images). > >This means that images built by debian-cd (like netinst) will have main >and non-free-firmware packages available under /firmware, with metadata >under /firmware/dep11, making it easy for hw-detect to: > > - Resolve firmware files (spotted as missing by looking at dmesg) into > firmware packages (if available), deploy those packages in the > installer environment, tweak apt-setup's default configuration, and > install those packages in the target environment. > > → Implemented by check-missing-firmware (detection & deployment in > the installer environment) and install-firmware hooks (enabling > apt-setup/non-free-firmware if relevant, installing in target > environment). > > - Detect firmware packages based on modalias information (in case > missing firmware didn't trigger lines in dmesg), not deploying them > in the installer environment, but queuing them for installation in > the target environment (also tweaking apt-setup's default config). > > → Implemented by install-firmware hooks.
Yup. >(Implementation detail: There are two install-firmware hooks, one after >base-installer, one before pkgsel.) > > ># 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. > >Even before working on non-free-firmware integration, there were many >possible combinations. With the ongoing work, we aim at making it easy >for most users to just get a successful installation, and I've proposed >to streamline alternate use cases (see #1029543), so that we can focus >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; I was thinking "hw-detect/load_firmware" might be better - we may want/need more firmware questions yet, so let's leave the namespace open? > - “firmware” or “fw” as an alias for shorter typing (“fw” feels like > extremely short); I'd just go for "firmware" here; "fw" might be confused with firewall (I see Andy had a similar thought). > - “never” value to skip firmware handling altogether, meaning skipping > both mechanisms mentioned above. Maybe, yeah. That's probably clearest. Then we'd default to "always". >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. Yup, good call. We can extend this more to add the nuanced options once we've got the basics - let's do it incrementally! -- Steve McIntyre, Cambridge, UK. st...@einval.com "C++ ate my sanity" -- Jon Rabone
