Hi,
Brian Potkin <claremont...@gmail.com> wrote (Sat, 27 Feb 2021 19:57:54 +0000):
> On Sat 27 Feb 2021 at 19:22:24 +0100, Holger Wansing wrote:
> > > A duplication of what the installer already provides.
>
> I'd have liked that addressed.
Not sure, what's meant here.
> > > > + .
> > > > + If you don't know what to enter, just leave it blank to not install
> > > > any
> > > > + additional packages.
> > >
> > > Have you thought of using tasksel to provide the installation of
> > > non-free packages?
> >
> > Using tasksel for this would just allow to display one simple line for
> > this topic ("Install firmware packages" or similar) and no possibility to
>
> "Install non-free firmware packages" would be the option. Why should
> it need more detail? The other entries aren't exactly locquacious.
>
> > give more detailed description, what this is or why this is needed (and
> > mention that this may need non-free).
> > This all is what the patch does.
> > And how to use tasksel: do you want to add a single task for every firmware
> > package? How many entries for such tasks would that be?
>
> A metapackage?
>
> > Or do you want to add just one task, and install all firmware packages we
> > have
> > in Debian at once, no matter which hardware is in the PC?
>
> Installing all firmware packages isn't unreasonable, surely? After
> all, xorg installs all video drivers. Nobody has complained yet.
Those xorg video drivers are not from non-free, right?
I think, that for non-free components a rule like "install all what's needed,
but not more" should count.
> > No, I think using tasksel for this is not suitable.
>
> How about early_command, late_command and pkgsel? These facilities
> are already provided by the installer. Why are they not suitable?
I don't get the benefit. Why is integrating that in pkgsel better than
in finish-install?
Maybe this sound a bit harsh, but you should know, that I'm not really
a coder, so I am probably lacking some basic understanding here.
And this also the reason, why I only have a very minimalistic solution here:
that's all I can provide, I'm lacking skills for "the big and perfect
solution".
If someone wants to step in and provide another solution - perfect!
However, we are in soft freeze now, so I fear it's too late for integration
of isenkram or the like, as mentioned by kibi (since that would require a
new udeb or new binary in some udeb, if I understand it right).
Holger
--
Holger Wansing <hwans...@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
