This was definitely a mistake made when preparing the original LXC 5.0
snapshot for upload in Ubuntu.

LXC_DEVEL=1 should only ever be set when dealing with current snapshots of the 
upstream codebase.
Shipping an older snapshot with LXC_DEVEL=1 set will cause any tool that 
consumes liblxc and which needs to do feature detection to incorrectly expect 
that the liblxc version present on the system has that feature supported, at 
best causing build failures, at worst causing runtime crashes.

I can certainly see how this mess was created with 5.0.0 as we had to push a 
pre-release snapshot to the archive and keep the build on autotools due to 
issues with meson at the time (resolved in 5.0.1).
Using an upstream snapshot rather than a release tarball, caused the inclusion 
of the problematic LXC_DEVEL=1.

What's quite puzzling is how we ended up with the 5.0.1 upload also
having that LXC_DEVEL=1 bit be applied as a patch on top of it...
Looking at the changelog, it appears that Serge simply pulled all
changes following 5.0.1 from git, which he likely did mistakenly looking
at the master branch rather than the stable-5.0 branch which wouldn't
have had that particular change.


My opinion is that we really need to:
 - Drop the LXC_DEVEL=1 cherry-pick from noble, ideally merge with Debian to 
pull in the more current 5.0.3 too.
 - Drop the LXC_DEVEL=1 cherry-pick from both mantic and lunar
 - Add a batch to drop LXC_DEVEL=1 from the git snapshot of 5.0 that's in jammy

Additionally, I'd very strongly recommend that an autopkgtest test is
added to validate that no liblxc package ever ship with LXC_DEVEL=1 ever
again.

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