libvirt users - Sep 2022 - Help in porting smack related patches to meson build system

On Mon, Sep 19, 2022 at 16:31:25 +0000, Vishal Gupta (vishagu2)
wrote:
> Hi Peter ,
Hi,

I firstly want to ask you to avoid top-posting on technical mailing
lists. 
> 
> 
> 
> Thanks for ur reply .
> 
> 
> 
> Kirkstone is the latest release from Yocto foundation . details
https://docs.yoctoproject.org/dev/migration-guides/migration-4.0.html
> 
> 
> 
> Kirkstone support libvirt 8.10 
https://layers.openembedded.org/layerindex/recipe/3052/
>
>
>
> We are trying to port 2016 smack patch  "
https://listman.redhat.com/archives/libvir-list/2016-July/msg00456.html"  
for libvirt which is based on automake  make file
Okay so that is quite an old patch which was never finished and merged.
> But above patch is incompatible with libvirt 8.10 .as libvirt 8.1 supports
only meson
> 
> 
> I was just wondering if above smack patch is already ported for meson based
libvirt 8.10?
> 
> We have issue in porting m4/virt-smack.m4   to  meson.build file    .
virt-smack.m4    is define in 2016 smack patch
No it is not ported. I want to warn you though that porting the build
system part to meson will not be biggest of the problems.

1) The patch is more than 6 years old at this point

  There's quite a lot of change in libvirt during that time. Many
  helpers and internal APIs were refactored. The patch even once you
  port the build system will require *significant* rework to actually
  even compile.

2) libsmack (smack-utils) used by the new security module is not present
   in distros

  The library it requires doesn't seem to be adopted much:

  https://repology.org/project/smack-utils/versions

  Did you make sure that it's present in your environment?

Additionally if you want to get the patch accepted upstream note that
there were outstanding problems with the patch in the last version
which is on the mailing list. I can see that there are definitely
problems with coding style and the patch will need to be split to
logical chunks as it's now just a big blob of code.

Also given that the library is simply not present in distros it will
require a justification why upstream should cary the patch. Carying
code which is not compiled because of lack of dependencies is a burden
to upstream and still can bitrot in the future.

Even if you are not striving for upstreaming the patch, be prepared for
more work than just porting the build system.