Re: What's the deal with discover*? (was: Processed: pending since 2013?)
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.
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.
Did that answer the question?
--
Happy hacking
Petter Reinholdtsen
Reply to: