On 4/29/19 10:03 AM, Pavel Hrdina wrote: > On Mon, Apr 29, 2019 at 02:22:21PM +0200, Pavel Hrdina wrote: >> On Mon, Apr 29, 2019 at 02:13:21PM +0200, Fabiano Fidêncio wrote: >>> On Mon, Apr 29, 2019 at 1:42 PM Pavel Hrdina <phrdina@xxxxxxxxxx> wrote: >>>> >>>> On Thu, Apr 25, 2019 at 03:42:36PM +0200, Fabiano Fidêncio wrote: >>>>> When performing a tree based unattended installation, some distros >>>>> require extra arguments to be passed to the kernel command line. >>>>> >>>>> Although those extra arguments are handled by >>>>> _OsVariant::get_kernel_url_arg(), it's libosinfo responsability to >>>>> properly inform them to the management apps. >>>>> >>>>> With that in mind and knowing that osinfo-db has been updated >>>>> accordingly, we can fully rely on the command line returned by libosinfo >>>>> and stop appending arguments returned by get_kernel_url_arg() when >>>>> performing unattended installations. >>>> >>>> What happens if there is osinfo-db version installed that supports >>>> unattended installation but the cmdline is still broken? >>> >>> Then the cmdline would be broken. >>> However, as there's *no* released code with unattended installation >>> functionality, I think that those changes may be fine, Mainly because >>> once we do release virt-manager we'd add a Requires: osinfo-db >= >>> specific version. >> >> Do we really want to have that strict dependency? It would make sense >> for some core functionality but this is a nice to have feature so I >> would rather have it optional. > > After some off-list discussion I'm OK with this patch, but we need to > make sure that unattended installation is optional feature in > virt-manager and will work only with osinfo-db version that contains > the patches mentioned in commit message. > > We will have to improve the code to warn user that unattended > installation is not available if they have old osinfo-db and > libosinfo. > > We should not definitely add a new dependency on specific osinfo-db > version as we don't depend on that package at all, we depend only on > libosinfo. > Agreed on the hard dep, we should not add one. Generally if we are depending on a new osinfo API we can use hasattr() to check for needed support, but it's not obvious in this case how we can do that. There's probably some way though - Cole _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
