On 05/10/22 13:10, Richard W.M. Jones wrote:> On Tue, May 10, 2022 at 12:09:38PM +0200, Laszlo Ersek wrote:>> One thing to note is that libguestfs itself does not *consume* the >> particular "common" contents that it generates. Therefore we don't have >> a reference loop in practice. What we have is this dependency graph: >> >> libguestfs (generator) >> | >> v >> libguestfs-common (generated content) >> / \ >> v v >> guestfs-tools virt-v2v >> >> Because of that, the usual "update common submodule" hunk *need not* be >> squashed into the libguestfs (generator) patches, when merging this. >> However, said "update common submodule" hunk does have to be squashed >> into the (single) guestfs-tools and virt-v2v patches, when merging. > > To be clear, while there isn't a separate "update common submodule" > commit in libguestfs, the commit hash of libguestfs -> common > submodule *will* still change (in the same commit that changes the > generator)?I'll merge the libguestfs-common patch set, and the libguestfs patch set, in unspecified order. Then there *will* be a separate commit in libguestfs that updates the submodule reference. It's just that this change will be an entirely stand-alone commit -- the submodule update hunk need not be squashed into any of the other -- actual patch -- libguestfs commits. In other words, in the git history, there will be two stages where the generator will output such content under "common" that actually differs from the then-checked-out submodule content -- but that's fine, because libguestfs itself does not "consume back" the same content. So this (temporary) difference is harmless. For guestfs-tools and virt-v2v however, the difference is not tolerable. Therefore, in each of those superprojects, I will extend the one patch for that superproject, with the submodule update. So that the submodule checkout and the dependent code advance in sync.> I looked at the patches through the mailing list archives and > everything looks fine to me so you might as well push it all. If > there are any problems I'm sure we'll find out soon enough.Thanks!> > For the whole series: > > Acked-by: Richard W.M. Jones <rjones at redhat.com> > > (You don't need to add this because I guess it will mess up your > carefully curated git commit hashes!)I will add it -- first because I have to extend the guestfs-tools and virt-v2v patches for merging, like described above, anyway; second, I need to be prepared for libguestfs-common moving forward mid-review in any case. (I shouldn't expect actual conflicts, but the commit hash of the HEAD could change.) I'll report back with the actual commit ranges. Thanks! Laszlo
Richard W.M. Jones
2022-May-10 12:21 UTC
[Libguestfs] SELinux relabeling: do it by default
On Tue, May 10, 2022 at 01:53:26PM +0200, Laszlo Ersek wrote:> On 05/10/22 13:10, Richard W.M. Jones wrote: > > On Tue, May 10, 2022 at 12:09:38PM +0200, Laszlo Ersek wrote: > > >> One thing to note is that libguestfs itself does not *consume* the > >> particular "common" contents that it generates. Therefore we don't have > >> a reference loop in practice. What we have is this dependency graph: > >> > >> libguestfs (generator) > >> | > >> v > >> libguestfs-common (generated content) > >> / \ > >> v v > >> guestfs-tools virt-v2v > >> > >> Because of that, the usual "update common submodule" hunk *need not* be > >> squashed into the libguestfs (generator) patches, when merging this. > >> However, said "update common submodule" hunk does have to be squashed > >> into the (single) guestfs-tools and virt-v2v patches, when merging. > > > > To be clear, while there isn't a separate "update common submodule" > > commit in libguestfs, the commit hash of libguestfs -> common > > submodule *will* still change (in the same commit that changes the > > generator)? > > I'll merge the libguestfs-common patch set, and the libguestfs patch > set, in unspecified order. > > Then there *will* be a separate commit in libguestfs that updates the > submodule reference. It's just that this change will be an entirely > stand-alone commit -- the submodule update hunk need not be squashed > into any of the other -- actual patch -- libguestfs commits.Right, I totally missed that the hunk "*need not* be squashed". Anyway it's all good.> In other words, in the git history, there will be two stages where the > generator will output such content under "common" that actually differs > from the then-checked-out submodule content -- but that's fine, because > libguestfs itself does not "consume back" the same content. So this > (temporary) difference is harmless. > > For guestfs-tools and virt-v2v however, the difference is not tolerable. > Therefore, in each of those superprojects, I will extend the one patch > for that superproject, with the submodule update. So that the submodule > checkout and the dependent code advance in sync. > > > I looked at the patches through the mailing list archives and > > everything looks fine to me so you might as well push it all. If > > there are any problems I'm sure we'll find out soon enough. > > Thanks! > > > > > For the whole series: > > > > Acked-by: Richard W.M. Jones <rjones at redhat.com> > > > > (You don't need to add this because I guess it will mess up your > > carefully curated git commit hashes!) > > I will add it -- first because I have to extend the guestfs-tools and > virt-v2v patches for merging, like described above, anyway; second, I > need to be prepared for libguestfs-common moving forward mid-review in > any case. (I shouldn't expect actual conflicts, but the commit hash of > the HEAD could change.) > > I'll report back with the actual commit ranges.Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html