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
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
