[Fedora-packaging] Extending the Static Library Packaging Guidelines to cover inline/template code

[Ralf Corsepius]

On 04/30/2012 09:53 AM, Michael Schwendt wrote:
> On Mon, 30 Apr 2012 06:02:05 +0200, RC (Ralf) wrote:
>
>> On 04/28/2012 04:31 PM, Toshio Kuratomi wrote:
>>> On Sat, Apr 28, 2012 at 08:56:20AM -0500, Rex Dieter wrote:
>>>> On 04/28/2012 04:57 AM, Michael Schwendt wrote:
>>>>> What does the Packaging Committee think about the following?
>>>>>
>>>>> [...]
>>>>>
>>>>> https://bugzilla.redhat.com/759823  is the review request for libkdtree++
>>>>>
>>>>> That is a C++ template container implementation, which does not build a
>>>>> shared library file to link with, but ships only C++ templates in header
>>>>> files.
>>>>>
>>>>> The resulting -devel package needs to be handled in the same way than
>>>>> a -static library package. Whenever there are important fixes in the
>>>>> templates, dependencies may need to be rebuilt. Not limited to security
>>>>> vulnerabilities. Any bug-fixes in the template implementation would only
>>>>> propagate to applications when rebuilding the application packages.
>>>>
>>>> +1, sounds similar to eigen2-devel and eigen3-devel
>>>>
>>> +1 as well.
>>
>> At first thought, I was inclined to agree, but ...
>>
>> ... where do you want to draw the line between "static template usage"
>> and "regular external code usage"?
>
> This is too vague for me to comment on. Have you read my comment in the
> bugzilla ticket? I might answer your question as it also points out what
> you write below.

I don't understand what you want to hear.

There are packages which, at build time include headers from other 
packages and use inlined-only code, defines-only code from these 
headers, without actually pulling-in run-time dependencies on 
corresponding libraries (the lib*.so, etc.).

I.e. these packages inherit the bugs/changes these inlines/defines-only 
code fragments may contain and nobody will notice.

Now, adding explict tags for "inlines/defines-only" devel-packages only 
covers a very small subset of such cases. The mixed cases are much more 
common.

In this context, my "where to draw the line" question was aiming at 
"when do you want a package to be treated specially?".
To exaggerate: Is adding a stub library to a "header only" package 
enough to exclude if from special treatment?


To cover "mixed cases", one would have to track each and every single 
define, inline and even types in all headers, everywhere, because 
changes to them can introduce run-time incompatibilities.

Imagine a library to change one of its public types from int to short or 
moving around some #defines in one of its headers, The result would be 
silent and often unnotices havoc at run-time.

>> These days, almost all C++ packages export C++-template headers, which
>> occassionally can be used without pulling in explicit library linkage.
>>
>> Similar considerations apply to plain C-packages which, may contain
>> freestanding inline-code and/or freestanding-defines.
>
> Of course! There are C header-only libraries, too.
I am not talking about "whole libraries". I am talking about individual 
files.

Somewhat oversimplied, my claim is, explicitly "tracking header-only" 
packages is of very limited use, because they only covers a small subset 
of such potential cases.

Also changes to inlines/defines etc. does not necessary mean run-time 
desaster. What matter is the API/ABIs a package's set of headers specifies.

> And it could be that
> these never will require a security related fix, but what about bug-fixes?
>
>> I.e. I think this proposal is not clear enough to be applicable.
>
> So far it's not more than a request for comments specific to header-only
> -devel packages. They are special and lead to special requirements.
>
> I wonder how we handle -devel packages which contain such code?
Almost all *-devel packages potentially have this issue, because 
packages which do not use #defines are rare.

AFAU, we don't handle this case at all, but trust in upstreams doing a 
reasonable job and in packagers doing so as well.

> Btw, the static lib packaging guidelines aren't bullet-proof either.
Sure.

> But at least one can query for -static BuildRequires and roughly compare
> build timestamps of packages to decide whether to rebuild dependencies.

Ralf