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.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/2039873

Title:
  liblxc-dev was built with LXC_DEVEL=1 in Ubuntu Jammy/Kinetic

Status in lxc package in Ubuntu:
  Confirmed

Bug description:
  [ Impact ]

  LXC 5.0.0 was built with LXC_DEVEL=1 set for Jammy. But for release
  build we should have LXC_DEVEL=0.

  LXC_DEVEL is a variable that appears in the /usr/include/lxc/version.h
  and then can be (and actually it is) used by other projects to detect
  if liblxc-dev is a development build or stable.

  Having LXC_DEVEL=1 makes problems for the users who want to build projects 
those are depend on liblxc
  from source (for example, LXD, go-lxc: 
https://github.com/canonical/lxd/pull/12420).

  Q: Why it was not a problem for so long?
  A: Because LXC API was stable for a long time, but recently we have extended 
liblxc API (https://github.com/lxc/lxc/pull/4260) and dependant package go-lxc 
was updated too (https://github.com/lxc/go-lxc/pull/166).
  This change was developed properly to be backward compatible with the old 
versions of liblxc. But, there is a problem. If LXC_DEVEL=1 then the macro 
check VERSION_AT_LEAST 
(https://github.com/lxc/go-lxc/blob/ccae595aa49e779f7ecc9250329967aa546acd31/lxc-binding.h#L7)
 is disabled. That's why we should *not* have LXC_DEVEL=1 for *any* release 
build of LXC.

  [ Test Plan ]

  Install liblxc-dev package and check /usr/include/lxc/version.h file
  LXC_DEVEL should be 0

  [ Where problems could occur ]

  Theoretically, build of a software which depends on liblxc-dev may start to 
fail
  if it assumes that LXC_DEVEL is 1.

  [ Other Info ]

  -

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2039873/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to