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?
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
>>> 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,
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