[Libguestfs] SELinux relabeling: do it by default

[Laszlo Ersek]

On 05/10/22 14:21, Richard W.M. Jones wrote:
> 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.

libguestfs commit range 00b9ef239342..08c4ac90f5a3
libguestfs-common commit range 81f86a0058a9..48527b8768d7
guestfs-tools commit 19de3d1c8d4e
virt-v2v commit 0c24fc6015ce

Thanks!
Laszlo