[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libguestfs] packaging virtio-win

On Mon, 2015-11-30 at 17:56 -0500, Cole Robinson wrote:
> On 11/27/2015 12:16 PM, Roman Kagan wrote:
> > On Thu, Nov 26, 2015 at 06:29:45PM -0600, Jeff Nelson wrote:
> >> On Thu, Nov 26, 2015 at 08:12:41PM +0300, Roman Kagan wrote:
> >>> 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.
> > 
> > Thanks a lot, I'll look into it early next week.
> > 
> Sorry I'm only getting to this thread now :/
> I'd like to try and summarize the interrelated packaging changes that were
> mentioned in this thread:
> - The iso layout is not optimal for programmatic consumption
> - The iso layout is not compatible with windows driver media autodetect
> conventions
> - The iso and RPM host contents do not match
> - The reasoning behind the iso/RPM layout is not clear
> To all this I say... preach, my brother :)
> https://bugzilla.redhat.com/show_bug.cgi?id=1217658
> https://bugzilla.redhat.com/show_bug.cgi?id=1167941
> The ISO and RPM layout is largely the result of organic extensions and no one
> ever tried to streamline things, so I fully support any work in that
> direction. But the things to consider:
> - There are many consumers of the iso layout as it is right now. Any changes
> in the short to medium term need to be entirely additive so we can get the new
> layout right without breaking every consumer. So keep the existing iso layout
> of $drivername/$weird-os/$arch, but _add_ the $arch/$standard-os/* layout, and
> avoid duplicates by hardlinking identical files (the scripts on github already
> have code that handles the last bit). In fact it might be a good starting
> point to write a script that takes the existing iso, extracts it, and
> rearranges the contents to match the new format. Then I could help integrate
> that with the scripts and my own testing.
> - The layout should use the latest windows conventions for arch/osname. If
> this means we have to diverge from the naming convention we currently use for
> RPM host installed drivers, that's fine, since we can maintain back compat
> there with symlinks. However I've tried searching for this info (googling
> 'windows driver cd layout/hierarchy/format') but I can't find anything
> definitive... anyone have a pointer? Especially WRT the current standard vs.
> the pre-windows-7 standard that vadim pointed out.

I don't remember all details, but there are some traces left in


> - Anything regarding a separate iso with a separate layout to appease < win7
> windows vintage should be handled separately, if at all IMO
> > I guess there's no mailing list, so I'll have to do pull requests on
> > github, right?
> Let's stick with email and virt-tools-list redhat com since there may be lots
> of discussion...
> Thanks,
> Cole

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]