[virt-tools-list] [virt-manager PATCH] installertreemedia, unattended: Only use kernel args from libosinfo

[Cole Robinson]

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 at redhat.com> 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