Hi Aleksandr,

Let me try to clarify this for you. The two options presented by you are
not what we want. We want to grab the package from Debian unstable (with
the latest changes) and merge what we have in Ubuntu, which means having
a complete changelog (including the previous Ubuntu changes). You can
find some info about the merge process here:

https://wiki.ubuntu.com/UbuntuDevelopment/Merging

There is some outdated content there (like using bzr), if you want to do
this using git properly you can try to use the workflow described here:

https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow

This is also some good content maintained by the Canonical Server team
which explains well the package merge process in our team's perspective:

https://github.com/canonical/ubuntu-maintainers-
handbook/blob/main/PackageMerging.md

I hope that's useful.

Now, I took a quick look at the proposed changes and I believe you
should double check the necessity of those binary packages name changes.
We are providing some transitional packages since Jammy, maybe now it is
time to get rid off them. In Debian, those transitional packages do not
exist, a good a idea (since we are merging our changes with Debian
again) might be to follow the package names from Debian. If it makes
sense, this will make the package way simpler. As a data point, the
Ubuntu package provides 12 binary packages and the Debian one provides 6
binary packages.

In the debian/tests/control file you need to add a comma (',') between
the two restriction names. A comment here is that if you merge the
changes from Debian we will get 2 more DEP-8 tests (autopkgtest) in the
package.

Nitpick: you committed the debian/files file which is not necessary.

-- 
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 22.04 and later
  releases

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