On 06.05.22 08:53, Steve Langasek wrote:
Hi Andreas,
On Thu, May 05, 2022 at 05:33:37PM -0300, Andreas Hasenack wrote:
Hi,
this came up again in a review, and I wanted to ask a broader audience.
How to we send LTO[1] related delta to Debian, given that Debian isn't
using LTO (yet)?
Case in point was the ust package[2], which has this bit[3] part of
the delta (just showing the first hunk):
@@ -1,5 +1,5 @@
liblttng-ust-python-agent.so.1 liblttng-ust-python-agent1 #MINVER#
* Build-Depends-Package: liblttng-ust-dev
- __start_lttng_ust_tracepoints_ptrs@Base 2.13.0
- __stop_lttng_ust_tracepoints_ptrs@Base 2.13.0
+ (optional=lto)__start_lttng_ust_tracepoints_ptrs@Base 2.13.0
+ (optional=lto)__stop_lttng_ust_tracepoints_ptrs@Base 2.13.0
Is this upstreamable to Debian as is? I know this depends most of the
time on the maintainer, but in general what would be our arguments?
Does it change the behavior of package building when lto is not used?
In a non-lto case, would the disappearance of those symbols be caught?
When talking about upstreaming of changes to .symbols files, I prefer to
argue it from a higher level: the two purposes of .symbols files are 1) to
avoid user-affecting bugginess due to undetected ABI breakage, and 2) to
ensure library dependencies are as relaxed as possible to give the best
cross-release binary compatibility and minimize constraints on release
upgrades.
While in our case it's LTO that has resulted in these particular symbols
disappearing, it's obvious from the names that these symbols are not
intended to be part of the public ABI of this library - the fact that these
symbols are exported is an accident, not something happening by design.
So marking these symbols "optional" makes the packaging more correct in
terms of describing the library's ABI, and more portable with respect to a
variety of compiler options that may change the exposure of internal
symbols.
Thus it's a low-priority bug for Debian, but the change is intrinsically
correct - not something Ubuntu-specific.
symbols files are broken by design. however that design error was accepted into
dpkg and issues mitigating that by either using the google or redhat solutions
are ignored. so please be pragmatic about this and try to work around it. so
yes, an issue for Debian to address these issues is appropriate.
Matthias
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
