[Libguestfs] SELinux relabeling: do it by default

[Richard W.M. Jones]

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