Re: Extending the Static Library Packaging Guidelines to cover inline/template code
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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.
I am not talking about "whole libraries". I am talking about individual files.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.
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.
Almost all *-devel packages potentially have this issue, because packages which do not use #defines are rare.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?
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.
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
[Home] [Fedora Legacy] [Fedora Desktop] [Red Hat 9 Bible] [Fedora Bible] [Fedora SELinux] [Big List of Linux Books] [Yosemite News] [Yosemite Photos] [KDE Users] [Fedora Tools]