[Libosinfo] [PATCH] win7, winxp: Upgrade spice-guest-tools to 0.100
Zeeshan Ali (Khattak)
zeeshanak at gnome.org
Wed May 11 16:26:10 UTC 2016
Hi,
On Mon, May 9, 2016 at 1:43 PM, Fabiano Fidêncio <fabiano at fidencio.org> wrote:
> Zeeshan,
>
> On Mon, May 9, 2016 at 12:59 PM, Zeeshan Ali (Khattak)
> <zeeshanak at gnome.org> wrote:
>> Hi Fabiano,
>>
>> On Fri, May 6, 2016 at 11:00 PM, Fabiano Fidêncio <fidencio at redhat.com> wrote:
>>> On Thu, May 5, 2016 at 9:10 PM, Zeeshan Ali (Khattak)
>>> <zeeshanak at gnome.org> wrote:
>>>> ---
>>>> data/os/microsoft.com/win-7.xml.in | 8 ++++----
>>>> data/os/microsoft.com/win-xp.xml.in | 8 ++++----
>>>> 2 files changed, 8 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/data/os/microsoft.com/win-7.xml.in b/data/os/microsoft.com/win-7.xml.in
>>>> index 2cb6488..8da4ccb 100644
>>>> --- a/data/os/microsoft.com/win-7.xml.in
>>>> +++ b/data/os/microsoft.com/win-7.xml.in
>>>> @@ -205,8 +205,8 @@
>>>>
>>>> <!-- All virtio and QXL device drivers, and spice-vdagent -->
>>>> <driver arch="i686" location="https://zeenix.fedorapeople.org/drivers/win-tools/postinst" signed="false">
>>>> - <file>spice-guest-tools-0.65.exe</file>
>>>> - <file>spice-guest-tools-0.65.cmd</file>
>>>> + <file>spice-guest-tools-0.100.exe</file>
>>>> + <file>spice-guest-tools-0.100.cmd</file>
>>>> <file>redhat09.cer</file>
>>>> <file>redhat10.cer</file>
>>>
>>> I've noticed that these certificate files are not used anymore with
>>> the spice-guest-tools-0.100. So, is there any reason for keeping those
>>> files here?
>>
>> I was not aware of that. I was under the impression that they are
>> required by Windows.
>
> According to https://zeenix.fedorapeople.org/drivers/win-tools/postinst/spice-guest-tools-0.74.cmd
> they are.
> But then you removed the files for the 0.100.cmd file and that's the
> reason I thought they are not needed anymore.
> So, most likely they are still needed and those lines got removed
> mistakenly, is it?
Removed where? I have not removed any files.
> How did you test the 0.100.cmd file?
I have not, yet, no.
>>> Also, spice-space.org provides a direct link for the latest driver[0],
>>> what makes the maintainability easier. Why not start using that for
>>> the spice-guest-tools?
>>
>> Well the API/XML allows for only one location per driver so if we can
>> ditch both certificate and cmd files, we can simply direct to the
>> official location.
>>
>>> Another question that comes to my mind is why don't we generate/keep
>>> the .cmd file inside libosinfo as we do for the installation scripts?
>>
>> Because it's driver-specific (it's only meant to pass the /S flag to
>> actual driver binary) and installation scripts are kept generic and
>> independent of drivers. App is informed of the driver from the OS
>> entry and if it decides to install them, it copies them to install
>> disk and informs the scripts about location of driver files and
>> scripts then just install binaries, as instructed by the app.
>>
>> Feel free to suggest a better way of handing this.
>>
>>
>
> Being completely honest here, I do believe the best way to handle the
> installation of spice-guest-tools is not on libosinfo neither on
> gnome-boxes.
> It seems as one the things that must be handled by
> libvirt-designer/builder in the future.
libvirt-designer/builder are not going to be made of magic. They are
going to rely heavily on libosinfo and will have a lot of code/logic
that currently Boxes has. So they are not going to solve anything for
libosinfo. If you have a suggestion on how to do things better
(through these libraries), it should apply to Boxes currently.
> So, my suggestion for now is to keep those files under
> spice-space.org. In the same way we have the
> spice-guest-tools-latest.exe we can have the
> spice-guest-tools-latest.cmd and the certificates (if they are really
> needed). IMO, it would make the maintainability easier as it would be
> done for free, for every release.
>
> Christophe, Zeeshan, what do you think about my suggestion?
Sure. Someone else would need to make it happen though. :)
--
Regards,
Zeeshan Ali (Khattak)
More information about the Libosinfo
mailing list