Hi, And thanks for the details.
Petter Reinholdtsen <p...@debian.org> (2016-01-09): > Not quite sure what the question is, but I'll try to provide some > background information on discover in the hope that it might answer at > least part of the question. It seems a "VCS" word was missing in my earlier mail. Knowing where the code lives for both discover and discover-data (so we can update them, see ongoing changes) and whether debian-boot@ is really meant to be the maintainer were my initial questions. > The task today of the discover package in the installation phrase is to > ensure hardware specific packages are installed. It ensure the software > needed to configure RAID controllers or talk to smart card readers is > installed automatically on machines with such hardware. It provide a > binary package and a data package, and the data package contain XML > files with mappings from hardware and kernel modules to packages in the > archive. I believe this feature should be replaced with a system > allowing each package maintainer to announce the hardware supported by a > given package in the package itself, and have been work on this for a > few years. > > Until a few years ago, this was the only source of mappings from > hardware to packages in Debian. Since then, I wrote the isenkram system > to do a similar task and more. The isenkram system in addition to the > simple hardware->package mapping provide a user space daemon that will > pop up a dialog when new hardware is inserted (think USB dongles), if > there is some (not yet installed) package in the archive supporting the > dongle. The isenkram system was bootstrapped with the information from > the discover-data, and extended with more information I could find. > Since a few weeks ago. The appstream system has been extended with > hardware information, allowing isenkram since a few weeks ago to fetch > hardware mappings from appstream. So far only one package use this in > Debian (pymissile), but I hope to find time to send bug reports asking > the other packages to list their supported hardware too. So far I have > only done it for one package, > > The isenkram-cli package provide two tasksel tasks, which I suspect is a > better approach for enabling the code to install hardware specific > packages. If isenkram-cli is installed before tasksel is executed, the > user get two options extra in tasksel, installing hardware specific > packages, and installing firmware packages needed by the currently set > of loaded kernel modules. > > My plan for the next release has been to adjust hw-setup to no longer > install discover but install isenkram-cli instead, and move the > hardware->package database from the isenkram package into the appstream > metadata database. It is a judgement call when isenkram is good enough > to replace discover, while still ensuring the Debian installation > install the hardware specific packages needed to get machines working > properly. Perhaps the time has come? > > Earlier, the discover package was useful for mapping hardware to kernel > modules, but this has not been useful for several years as the udev > system handle this just fine with the mapping tables provided by the > kernel itself. Because of this, that part of the discover-data dataset > has been ignored and can be removed. This was the original purpose of > discover, but is no longer a useful part of its feature set. It's probably a good idea to consider such a move, but I'd rather concentrate on updating discover* for the non-free/firmware thing first. I'm making a note locally (but my to do list is ever-growing), but feel free to file a bug report against src:debian-installer or d-i.debian.org (where I keep infrastructure-related and cross-packages bug reports) to make sure it's easily found by others. Mraw, KiBi.
signature.asc
Description: Digital signature
