Bug#929187: libbpf soversion does not match the package name
On Sun, 2019-05-19 at 14:29 +0100, Ben Hutchings wrote: > On Sun, 2019-05-19 at 00:34 +0100, Ben Hutchings wrote: > > Package: src:linux > > Version: 4.19.37-3 > > Severity: serious > > > > We currently use $(make kernelversion) to generate the soversion, > > resulting in 3 components of the upstream version (currently > > 4.19.37), > > whereas the package name only uses 2 components (currently 4.19). We > > really want the latter as we don't expect the ABI to change in a > > stable update. > > > > There is an additional bug that building perf also rebuilds libbpf. > > This seems to set some environment variables such that the soversion > > changes again, duplicating the second component and resulting in > > 4.19.19.37! > [...] > > In fact, perf seems to successfully build libbpf.a in its own output > directory, so it's not at fault. > > However, the default "all" target in the libbpf Makefile somehow loses > the output directory, so we end up with an in-tree build! This results > in object files being present in the linux-source package. > > The "install" target doesn't do this, so I think this results in the > library being built yet again, finally in the right directory. I'm not > entirely sure. Wait, no, we don't actually pass the output directory! I should document the requirement for out-of-tree builds in README.source. Ben. -- Ben Hutchings If the facts do not conform to your theory, they must be disposed of. signature.asc Description: This is a digitally signed message part
Bug#929187: libbpf soversion does not match the package name
On Sun, 2019-05-19 at 00:34 +0100, Ben Hutchings wrote: > Package: src:linux > Version: 4.19.37-3 > Severity: serious > > We currently use $(make kernelversion) to generate the soversion, > resulting in 3 components of the upstream version (currently > 4.19.37), > whereas the package name only uses 2 components (currently 4.19). We > really want the latter as we don't expect the ABI to change in a > stable update. > > There is an additional bug that building perf also rebuilds libbpf. > This seems to set some environment variables such that the soversion > changes again, duplicating the second component and resulting in > 4.19.19.37! [...] In fact, perf seems to successfully build libbpf.a in its own output directory, so it's not at fault. However, the default "all" target in the libbpf Makefile somehow loses the output directory, so we end up with an in-tree build! This results in object files being present in the linux-source package. The "install" target doesn't do this, so I think this results in the library being built yet again, finally in the right directory. I'm not entirely sure. Ben. -- Ben Hutchings If the facts do not conform to your theory, they must be disposed of. signature.asc Description: This is a digitally signed message part
Bug#929187: libbpf soversion does not match the package name
Package: src:linux Version: 4.19.37-3 Severity: serious We currently use $(make kernelversion) to generate the soversion, resulting in 3 components of the upstream version (currently 4.19.37), whereas the package name only uses 2 components (currently 4.19). We really want the latter as we don't expect the ABI to change in a stable update. There is an additional bug that building perf also rebuilds libbpf. This seems to set some environment variables such that the soversion changes again, duplicating the second component and resulting in 4.19.19.37! This is a violation of Debian policy: the binary package name must change if the soname changes. Ben. -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
