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