Sending LTO delta to Debian

[Matthias Klose]

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 at Base 2.13.0
>> - __stop_lttng_ust_tracepoints_ptrs at Base 2.13.0
>> + (optional=lto)__start_lttng_ust_tracepoints_ptrs at Base 2.13.0
>> + (optional=lto)__stop_lttng_ust_tracepoints_ptrs at 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