On Mon, Oct 23, 2023 at 04:27:16PM -0000, Aleksandr Mikhalitsyn wrote:
> >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

I meant the *Ubuntu* development release, not an upstream development
release.

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

I understand that, but that's not my question. You explained how it is
intended to be used. But how is it actually used?

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

Sure, but it is insufficient to consider just the reverse dependency
involved in the use case you're trying to fix. We must consider all
other reasonable use cases as well.

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

The risk is that some other project is dependent on this variable in
some way that has not been considered and will break if the change is
made.

> 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

For SRU purposes, it is not sufficient to rely on your "properly written
software" condition. We must also avoid regressing "improperly written
software" as much as we can in any change we make to a stable release.
In other words, "your software was written improperly and therefore the
fact that you, as a user, were regressed by our change to a stable
Ubuntu release is your problem and we don't care" would be an
unacceptable position to take if a user reported a regression as a
result of making this change.

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

Ah, sorry, I had assumed that VERSION_AT_LEAST was being defined by the
lxc source package. Nevertheless, a less-than-clean fix is what we
sometimes need to do in stable releases to minimise regression risk to
users. It can be gated on a build against a specific version to keep the
solution clean for the future, though. For example, in your build system
you could check if you're

But this also suggests that there isn't actually a bug that impacts a
binary that is shipped by Ubuntu in Jammy

Please reconsider:

1) What use cases might be regressed as a result of this change, even
for software that is not "properly written". This is a hard requirement
for any stable release update in Ubuntu.

2) In light of the above, what is an appropriate minimal way to fix the
issue.

Right now, based on the information you've provided and the criteria you
seem to have used for your analysis, it doesn't seem appropriate to make
this change in a stable release in Ubuntu, so I'm marking the bug as
Won't Fix for Jammy and unsubscribing ~ubuntu-sponsors.