Re: What's the deal with discover*?
> 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.
If someone got the time to do so, I believe that would be a good thing
to do. But my recommondation would be to switch to isenkram-cli with
appstream as the data souce and ask for the removal of discover.
> 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
I've already implemented this idea in isenkram. The isenkram-cli
package contain an embedded copy of the list of packages with files in
/lib/firmware/, fetched from the apt-file data set. This is part of the
background for my recommondation to move to isenkram-cli for mapping
hardware to firmware and user space packages.
When the same information is available from appstream, I suspect we want
to include appstream data on the installation media, instead of
embedding it in isenkram-cli.