On Mon, Feb 6, 2023, at 5:33 AM, Cyril Brulebois wrote:
> Hi Brandon,
>
> Brandon Werner <brandon_c...@fastmail.fm> (2023-02-06):
>> Thanks for your response. I have included the syslog lines from the
>> installer log you requested.
>
> OK, that's basically what I thought was happening, but it's always a
> good idea to check a hypothesis before deciding what to do about it. :)
>
> I think I might have mentioned the following in some discussion, or
> in some commit, but basically:
> - we have a list of requested files;
> - we have a list of requesting modules;
> - some modules get reloaded.
>
> If we maintain a module/file mapping, we could:
> - decide which modules need to be reloaded, instead of iterating on all
> of them (that's part of the reason why I had this idea in mind in the
> first place, looking around how to “reload dance” was implemented:
> walking through all modules unconditionally);
> - decide that a module is “good to go” as soon as it's been reloaded
> once, i.e. some of the files it requested have been found.
>
> The second part would make the point about “required” vs. “optional”
> firmware moot, and would prevent extra dialogs. One could argue that
> maybe some other *.deb somewhere could be more recent or could have
> extra files, but then we don't implement anything when it comes to
> multiplicity anyway, so that wouldn't be a regression.
>
> Alternatively, we could keep the unconditionally reload dance, while
> still keeping track of files requested by each module over time.
> When the list gets smaller, its files start getting ignored.
>
>
> Does that make sense to you?
This makes sense, and both solutions seem like they would work. It seems like
the second solution of keeping the unconditional reload and testing if the list
of files was smaller after the reload would be easier to implement for
Bookworm, but I think you and the rest of the installer team are better
informed to make that decision. :)
I think assuming the module is working if the list of requested files is
smaller after a reload is a fairly safe bet for network hardware, but If the
installer team implemented either of these solutions, I could test on a bunch
of old and new machines that are available at a computer club I attend. I
unfortunately don't feel like I personally understand the installer well enough
to fix this properly, and any merge request I would create would be a sad hack.
Hopefully many folks will be testing Alpha 2 of Bookworm as well, to find any
problems that would result from a change like this.
