[Libguestfs] packaging virtio-win (was: Re: [PATCH] v2v: virtio-win: include *.dll too)

[Jeff Nelson]

On Thu, Nov 26, 2015 at 08:12:41PM +0300, Roman Kagan wrote:
>On Tue, Nov 24, 2015 at 01:07:03PM +0000, Richard W.M. Jones wrote:
>> On Mon, Nov 23, 2015 at 08:26:10PM +0300, Roman Kagan wrote:
>> > Having given it some more thought and having discussed that with
>> > colleagues who do various things with the drivers, like generating
>> > unattended install helpers or just manually installing drivers into
>> > guests, I'm now of the opinion that neither libguestfs nor any other
>> > user of the drivers should look inside the driver files in order to
>> > match them against the guest OS, because it's hard for programs and
>> > unrealistic for humans.
>> >
>> > I tend to believe it should be the responsibility of the driver packages
>> > to lay out the drivers in a directory structure that both humans and
>> > programs could grok easily and that wouldn't change once established; in
>> > a sense this would be both an API and a human interface.
>> >
>> > If I were to lay it out I'd group the stuff by guest OS, so that for a
>> > particular guest a single entity -- a directory tree or a pre-created
>> > ISO or floppy image -- would contain all that's needed for this guest
>> > and nothing else.  This would allow separation of concerns, so that
>> > actors who bring the stuff into the guest wouldn't need to care about
>> > what's inside, and actors involved with its installation wouldn't need
>> > to know how to find the right one.
>>
>> The good news is that this is what we do right now.
>>
>> > E.g. from this POV the way drivers are stored in RHEL7 virtio-win
>> > package on the *filesystem* looks OK, the way they are stored in the
>> > *ISO image* in the same package doesn't.
>> >
>> > As for naming one can stick with what's being used in that virtio-win
>> > rpm, i.e.
>> >
>> > {amd64,i386}/Win{XP,2003,2008,2008R2,2012,2012R2,7,8,8.1}
>> >
>> > or switch to the names passed to inf2cat in its /os parameter, i.e.
>> >
>> > XP_X86,Server2003_X86,...,8_X64,Server8_X64,6_3_X86,6_3_X64,Server6_3_X64
>> > (https://msdn.microsoft.com/en-us/library/windows/hardware/ff547089(v=vs.85).aspx)
>> >
>> > Whatever convention is chosen it needs to be followed thereafter.
>>
>> Yup - very important that once we decide what the naming convention is
>> going to be, we stick with it.  Moving drivers around or using ad-hoc
>> naming schemes causes churn in virt-v2v and probably other projects
>> too.
>>
>> > The main problem with this proposal is that I don't know how to
>> > implement it: there are multiple vendors of virtio-win packages, and,
>> > for licensing reasons, they don't even share the source code, so it's
>> > unclear who could own this convention and enforce it on others.
>>
>> I guess that virt-v2v will have to deal with this with more special
>> rules.
>>
>> > I'd appreciate any thoughts or suggestions on how to proceed from that
>> > and whether it's worth it at all.
>
>Apparently I failed to inspire anybody who can affect the driver
>packaging layout :)  Let me try again.
>
>Do I get it right that the way virtio-win is packaged for Fedora and
>RHEL is driven by the scripts at
>
>https://github.com/crobinso/virtio-win-pkg-scripts
>
>and I should be submitting patches or pull requests to it?

Yes, that's what I use to package the drivers for RHEL.


>Or should the layout be determined only by the build machinery at
>
>https://github.com/YanVugenfirer/kvm-guest-drivers-windows
>
>and I should be direct my submissions that way?

I don't know, but if you work strictly with virtio-win-pkg-scripts it
shouldn't matter.


>Or any combination of the above?
>
>Also does anybody know this is done in SUSE?

No idea.

>Any help would be appreciated.
>
>Thanks,
>Roman.


-Jeff