On 5/3/19 10:24 AM, Fabiano Fidêncio wrote: > People, > > As part of libosinfo, we have a few tools: osinfo-detect, osinfo- > install-script, and osinfo-query. > > About osinfo-detect, it seems clear that the intetion of the tools is > to detect whether we're able to recognise a media or tree. It's output > is something like: > ``` > fidencio@laerte ~ $ osinfo-detect ~/Downloads/Fedora-Workstation- > netinst-x86_64-29-1.2.iso > Media is bootable. > Media is an installer for OS 'Fedora 29 Workstation' > > fidencio@laerte ~ $ osinfo-detect --format env ~/Downloads/Fedora- > Workstation-netinst-x86_64-29-1.2.iso > OSINFO_BOOTABLE=1 > OSINFO_INSTALLER=http://fedoraproject.org/fedora/29 > OSINFO_MEDIA=http://fedoraproject.org/fedora/29:1 > ``` > Now, the questions that come to my mind are: > - What kind of information should we return when a media is recognised? > - How the information would be used? By whom? > - Do we still care about --format env? > > Cole already filed an issue about osinfo-detect failing to recognise > s390 medias as bootlable and, in the past, I've already fixed detection > of PPC medias. So, apart from the questions raised above, there's a > clear need of improving our detection methods and it'll be done in the > future (as in, I'm aware of and have plans to work on this). > I've also filed some issues about osinfo-detect that would help Cockpit > usage of the tools. However, this doesn't apply anymore for Cockpit as > they're now using our APIs directly (but the may still apply for other > cosumers of the tools). > I suggest we only extend it if there's a clear use case for doing so. It's definitely useful as a quick 'can libosinfo even detect this media' tool, for devs and occasionally in bug reports. It was once specifically used for outputting some data to be tagged into udev db so boxes could tell the OS of the media in /dev/cdrom, but that's been solved alternately for a while now AFAICT If cockpit isn't dependent on it anymore, then I say let the tool lie until we have another compelling use case for extending it. Maybe spitting out an OS ID and then something like the osinfo-dump tool could be enough for shell scripts or apps that don't want to code directly to the API, but I don't think we need to be proactive about trying to cover those usecases. > About osinfo-install-script, it seems clear that the intention of the > tool is to generate an install script for a supported distro. However, > it doesn't generate any command line to be used together with the > script. In any case, I'm really interested to know: > - How those scripts are supposed to be consumed? > - What was the idea behind the tool when it was created? > - What do we want to achieve with this tool? (As in, who should be > consuming the generated script and how?) > Here's the cover letter when danpb added it: https://www.redhat.com/archives/virt-tools-list/2012-February/msg00236.html In the absence of proof that anyone is actually using the tool effectively, I'd say come up with some test case to make sure it isn't completely broken, and then not worry about it beyond that. For the kernel command line thing I'd just ignore it, there's already pieces of the unattended install process we leave up to apps like making the script available to the VM, let that tool just focus on generating a script. > Knowing those, I'll start filing some issues and improving the tool > accodingly. > > About osinfo-query, it seems to be created in order to check whether an > OS supports/has info about something or not. But, then, similar > questions come to my mind: > - Who should be using this tool and how? > - What kind of output shall we provide? > - What kind of info is really required to be there? > The tool is useful for listing all os that osinfo-db knows about. That's all I've every really used it for and at present all I can really think it's practically useful for, besides testing the libosinfo API. > Again, knowing those answers I'll start filing some issues and > improving the tool accordingly. > > Last but not least, two general questions that involves all the tools > we have and that may end up being answered by the questions raised > above: > > - Are those tools intended to be used together? As in: > - detect whether a media is recognised or not via osinfo-detect; > - use osinfo-detect output (or part of it) and pass it osinfo-query > in order to get its id > - use the parsed output of osinfo-query and pass it to osinfo- > install-script in order to generate an install script > > The example above may be a dummy one, but I'd really like to > understand how those tools can be connect and how ... or whether that > was not the intention at all (and then we should document it properly). > I don't think there was any grand intention for all of these to fit together as some sort of shell libosinfo API. It's easy to imagine ways to improve the tools and hypothetical use cases for doing so, but until there's an actual user with a compelling reason why they can't use the API and need more features from the shell tools, IMO dev time is better spent elsewhere. > - What to be tested on those tools in order to ensure we're not > introducing any regression on them? > - I'm asking this because I'd like to start adding test for those in > the very same way I've added tests for osinfo-db-tools. Yes this is important regardless, we should keep the current state working, or at least not obviously failing like crashing etc Thanks, Cole _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
