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&q... 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.