[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: What's the deal with discover*?


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).


Attachment: signature.asc
Description: Digital signature

Reply to: