Hi, Petter Reinholdtsen <pere@hungry.com> (2016-01-10): > In short, historical reasons from before your time. :) > > The packages discover and discover-data were taken under the wings of > debian-boot@ when Proginy stopped maintaining it, as it was the best > option to ensure a good installation experience in Debian due to its > excellent ability to map hardware to kernel modules and packages. But > no-one took the time to migrate the svn repo from its existing one to > the d-i one, and I guess it was forgotten when d-i migrated from > subversion to git. > > Note, building discover is a bit painful, and could use some work to > make it easier to maintain. So the question becomes: should they be moved to git? Keeping the manual as a special snowflake leaving under d-i's svn is OK (mostly to avoid translators' having to learn about a new tool), but keeping debian-boot maintained packages under a different scm under a different group seems a bad idea. > Well, isenkram have the /usr/sbin/isenkram-autoinstall-firmware script > to handle firmware packages, and it could be a good replacement. It is > using the equivalent of a 'apt-file search /lib/firmware/' to locate > packages with firmware in them. > > As far as I know, discover isn't used to find firmware packages any > more, so updates for discover seem irrelevant regarding the introduction > of a non-free-firmware section. The firmware handling is done by > hw-detect. I can probably help to get it updated to use the new > section, which seem like a very good idea to get computers working > without having to enable the entire non-free APT source. Right, for some reason I got hw-detect and discover confused. Maybe because you recently were involved with patching hw-detect. :D > One thing that would help a lot is to get the firmware packages to > announce their firmware using appstream metadata. This would make it a > lot easier to locate the correct firmware package, and would help both > isenkram and all others interested in operating on firmware data. I don't know a lot about appstream metadata, but I mentioned during the BoF we could just embed a fw file→fw package mapping at build time to ease lookup (basically what you're doing with apt-file, except we would have a static list in the d-i image; for one thing, there's no guarantee network is available at early stages to query Contents from mirrors). Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature