Hi Colin, and thanks for the write-up. Colin Watson <cjwatson@debian.org> (2017-01-21): > I think this part could be represented as YAML without too much trouble. > We'd have a list of probes giving the parsers they need, some > conditions, and templates for their output, perhaps with some kind of > include arrangement for subtests. The engine would iterate over the > tests, running parsers on demand, and use the first probe whose > conditions are satisfied. This would be easy to test: since this would > be separate from device manipulations, we could feed it a directory tree > and/or some simulated parser output and let it go from there. > > The existing documented command-line interface would be preserved > exactly as it is. The only integration issue for d-i would be that we'd > need a libyaml udeb, which shouldn't be a big deal (os-prober is only > used quite late, when it's used in the installer environment at all). > > Does anyone object to this outline plan, or have other considerations I > haven't taken into account? I propose to prototype this in Python (in > my copious free time of course ...) and then translate it to C once the > general shape of things is working. I'm very much in favor of having maintainable and testable things, so all of this looks good to me. There are a bunch of other areas where having something better than just shell fragments would be better, and maybe having python bits in the installer came up a few times in the past, even if it wasn't entirely clear whether that would work nicely (I think some comments were made about the python* upload frequency but I can't recall the exact details). IIRC partman and grub-installer are examples of items which could benefit from this. Anyway, I'm drifting here. Thanks so much for the heavy os-prober bug fixing, and for the proposed plan. All in! KiBi.
Attachment:
signature.asc
Description: Digital signature