On Tue, Apr 30, 2019 at 9:11 PM Cole Robinson <crobinso@xxxxxxxxxx> wrote: > > On 4/25/19 9:27 AM, Fabiano Fidêncio wrote: > > Tree based installations will need more info from the command line than > > what's currently provided by osinfo-db. > > > > For instance: > > - OpenSUSE requires "install=URL" > > - Silverblue requires "inst.repo=URL" > > - Fedora < 19 requires "method=URL" and >= 19 requires "inst.repo=URL" > > - CentOS/RedHat < 7 require "method=URL" and >= 7 require "inst.repo=URL" > > > > With those patches, management apps can rely solely in the command line > > generated by us for doing tree based installations. > > > > This is an improvement, but I was originally thinking we would expose > the kernel argument in some way that it could be queried by apps > directly. That way virt-install could eventually use it to drop our own > hardcoded method/inst.repo/install mapping and just depend on osinfo-db > to provide it. Maybe if we solve that problem too then the result will > look a bit different osinfo-db, at least for now, only cares about the kernel command line when dealing with a unattended installation. And the way we deal with that is: https://gitlab.com/libosinfo/libosinfo/blob/master/osinfo/osinfo_install_script.c#L1617 As far as I understand, your suggestion is to have the command-line needed by the unattended installation exposed "somewhere", so apps could query that even when not performing an unattended installation using our scripts/APIs, right? > > I'm not really sure how to best do that besides putting a > <kernel-url-arg> field or something in the <os>, but that seems > inflexible. Any ideas? Some way to query the unattended API objects for > this info? > A <kernel-url-arg/> attribute, under <os/>, may be the simplest way to go, with the new osinfo_os_get_kernel_url_argument() API. Daniel, what do you think? > - Cole If you have the time, please, file a ticket for that. if you don't have the time, I'll file the bug on Thursday. Best Regards, -- Fabiano Fidencio _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
