[ Note: I've added d-l-e to the loop since people there might have some insight about the prompt update I'm proposing. ]
Hi,
An email earlier today reminded me of this old topic: it would be nice
if hw-detect would point us to the right firmware package(s) instead of
letting D-I only report the list of missing firmware files.
I've modified hw-detect to make it possible to build (and update) such
a mapping:
${firmware_filename} ${firmware_package} ${section}
which is going to be shipped as usr/share/hw-detect/firmware-map in
the hw-detect binary.
Like choose-mirror, this file is generated outside of the source and
binary builds (since it needs network access), and will need updating
from time to time (ideally once before every release, but I'll probably
add a cron job on d-i.debian.org to get notifications).
=> The question is now: how do we present this to users?
The current template is:
| Template: hw-detect/load_firmware
| Type: boolean
| Default: true
| # :sl2:
| _Description: Load missing firmware from removable media?
| Some of your hardware needs non-free firmware files to operate. The
| firmware can be loaded from removable media, such as a USB stick or
| floppy.
| .
| The missing firmware files are: ${FILES}
| .
| If you have such media available now, insert it, and continue.
The FILES variable gets set by check-missing-firmware.sh through:
db_subst hw-detect/load_firmware FILES "$files"
and we could do the same with a PACKAGES variable which would contain
e.g.:
firmware-atheros (non-free), prism2-usb-firmware-installer (contrib)
(by looping over $files and grepping into this new mapping file.)
Quick idea:
| _Description: Load missing firmware from removable media?
| Some of your hardware needs non-free firmware files to operate. The
| firmware can be loaded from removable media, such as a USB stick or
| floppy.
| .
| The missing firmware files are: ${FILES}
| .
| The following packages contain some of these files: ${PACKAGES}
| .
| If you have such media available now, insert it, and continue.
The trick is: we might reach some point where (at least) it's not
possible to resolve a filename to a package. That's why I've used a
rather cautious wording above. Having an extra line with the list of
unresolved filenames would be cumbersome in the general case. Having it
only conditionally would mean having troubles translating it.
Maybe sticking to the simple sentence below would be appropriate for
most cases:
| They can be found in the following packages: ${PACKAGES}
What do you think?
KiBi.
signature.asc
Description: Digital signature
