Comment 13 for bug 2039873

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

Ugh. If applied/ubuntu/devel is the right branch to check it then it is not fixed in the Ubuntu development release too.

See:
https://git.launchpad.net/ubuntu/+source/lxc/tree/meson.build?h=applied/ubuntu/devel#n33

At the same time in Debian:
https://git.launchpad.net/ubuntu/+source/lxc/tree/meson.build?h=applied/debian/bookworm#n36

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

It is used precisely as it intended to be used (at least in the go-lxc) :)

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

Ok, let's take https://github.com/search?q=LXC_DEVEL&type=code
As I can see from the search results there is no any other use cases for LXC_DEVEL
anywhere except go-lxc.

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

Sure, I agree. But I'm 99.999% sure that this change is safe :)

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

It does not impacts a *binary*. But it impacts /usr/include/lxc/version.h file contents which is a
part of a liblxc-dev package.

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

Have done using https://github.com/search?q=LXC_DEVEL&type=code

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

I believe that my fix is the minimal appropriate way to fix the issue.