Re: Replace discover by isenkram in d-i, better integration with virtualizations/clouds

[Raphael Hertzog <hertzog@debian.org>]

Hi,

On Sun, 03 Dec 2017, Cyril Brulebois wrote:
> > I see mainly benefits to such a move. The only downside is that it
> > would pull python by default. This entirely depends on whether we want
> > to keep it installed or not. We could install it just to do a single
> > scan and install pass during installation and then get rid of it (this
> > would then likely be made configurable with a debconf preseed).
> 
> Well, I'm not sure it's really a good idea to put more packages in the
> default installation loop; we've been going the opposite direction for
> quite a while, and that seems like the right thing to do.

I think we want to be have a smaller minbase for use cases where it
matters but I don't think that we necessarily want less packages in
the default installation. In particular not when they add value,
which isenkram clearly does.

> Quick digression: As for virtualization and cloud support, it seems the
> cloud team has been working on standardizing a tool that fits most virt-
> & cloud- related needs (at least that's what I gathered from Steve's
> presentation during mini-DebConf in Cambridge), so I'm not entirely
> convinced by the net gain on the d-i side for this specific use case (if
> users are using something else entirely anyway…).

I'm not sure what tool you are referring to. In any case, I appreciate
that isenkram installs the correct packages for virtualbox,
vmware, etc.

While our official VM/cloud images are usually not built with
debian-installer, I stronly believe that d-i should have a nice behaviour
in VM and install the appropriate packages for the virtualization
technology in use.

If isenkram is not the solution to this, then we need something else.

> I have no idea about the isenkram architecture, but reusing the “data
> files mapping hardware to packages” part is probaby a good idea.

What do you mean by this?

Reusing the mapping database maintained in isenkram in the context of d-i?

I would like Petter to give a broader comparison of discover vs isenkram.
But I believe that isenkram is a bit smarter in that it doesn't only
handles devices ID discovered in PCI/USB/whatever buses but it also relies
on data from the system (dmidecode and stuff like that) to infer more
packages to install.

So it might not be trivially reusable in the context of discover for
example.

> Petter mentioned we could strip bits and pieces and only use something
> that wouldn't depend on the whole lot, but I lost count. (That was
> likely back when we had to deal with hw-detect and firmware support.)

Petter, do you have more details about your former discussions?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/