Comment 10 for bug 2039873

Dear Robie,

thanks for paying attention to this bug!

>Has this been fixed in the development release, and if so, how?

LXC_DEVEL is 1 in the development release:
https://github.com/lxc/lxc/blob/main/meson.build#L36

But LXC_DEVEL is 0 in *any* stable tag:
https://github.com/lxc/lxc/blob/lxc-5.0.3/meson.build#L36

And this is correct.

>It's not clear to me that making this change is the appropriate thing to do in an SRU. How is LXC_DEVEL used in practice?

LXC_DEVEL is used to determine if the liblxc is a cutting-edge development snapshot of the LXC or not.
So, it should be 1 *only* for the main branch of lxc. But in all stable version it is 0.

> Have you analysed known reverse dependencies to understand the impact of making this change? What did you find?

I have analyzed well-known reverse dependency go-lxc. It's used by LXD to communicate with liblxc C API.

>The only impact to users that I can understand from your explanation is that VERSION_AT_LEAST is disabled, causing builds outside the archive that use that macro to fail. Everything else seems to make the assumption that the correct way to fix this is to change LXC_DEVEL from 1 to 0, but without explaining why this is the minimal change possible.

Speaking honestly, I have no idea about other good ways to fix this. And this change seems to be a "minimal" for me because it does not change LXC code (and should not) it's just a matter of having proper build configuration.

>Is there any other actual real world impact?

I don't think that changing LXC_DEVEL to 0 can break any properly written code. For example, Debian folks have it disabled:
https://git.launchpad.net/ubuntu/+source/lxc/tree/meson.build?h=applied/debian/bookworm#n36

>Could you just patch to make VERSION_AT_LEAST work instead, for SRU purposes, to minimise regression risk?

Of course, we can patch go-lxc (go-lxc also part of the LXC project). But this will be a hacky and incorrect way to fix things.