[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):
> [Cyril Brulebois]
> > 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
> > mirrors).
> 
> 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.

Currently, there's no python in d-i, so isenkram is a no-go (as already
mentioned a few months ago).

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

Mraw,
KiBi.

Attachment: signature.asc
Description: Digital signature


Reply to: