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

Michael Schwendt mschwendt at gmail.com
Mon Apr 30 07:53:38 UTC 2012


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.

> 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. 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?
Do we assume that the packager treats them like an ordinary shared library
-devel package? Effectively announcing only version upgrades with API changes.
Or do we assume that the particular requirement to rebuild dependencies
for all important bug-fixes in the -devel package is known/understood and
will be handled appropriately?

For example, if users of this code can "BuildRequires: libkdtree++-devel"
who takes care of notifying them of bug-fixes in that package, which would
require a rebuild of dependencies? It may not be obvious to packagers of
dependencies that they build something with a -devel package that is special.
Even the libkdtree++ owner might forget about that.

Btw, the static lib packaging guidelines aren't bullet-proof either.
But at least one can query for -static BuildRequires and roughly compare
build timestamps of packages to decide whether to rebuild dependencies.

-- 
Fedora release 17 (Beefy Miracle) - Linux 3.3.4-1.fc17.x86_64
loadavg: 0.10 0.33 0.30


More information about the packaging mailing list