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

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.8...) > > 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.