FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 04-28-2012, 09:57 AM
Michael Schwendt
 
Default Extending the Static Library Packaging Guidelines to cover inline/template code

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.
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-28-2012, 01:56 PM
Rex Dieter
 
Default Extending the Static Library Packaging Guidelines to cover inline/template code

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

-- rex
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-28-2012, 02:31 PM
Toshio Kuratomi
 
Default Extending the Static Library Packaging Guidelines to cover inline/template code

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.

-Toshio
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-30-2012, 04:02 AM
Ralf Corsepius
 
Default Extending the Static Library Packaging Guidelines to cover inline/template code

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


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.


I.e. I think this proposal is not clear enough to be applicable.

Ralf

--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-30-2012, 07:53 AM
Michael Schwendt
 
Default Extending the Static Library Packaging Guidelines to cover inline/template code

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-30-2012, 09:07 AM
Ralf Corsepius
 
Default Extending the Static Library Packaging Guidelines to cover inline/template code

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 
Old 04-30-2012, 11:07 AM
Michael Schwendt
 
Default Extending the Static Library Packaging Guidelines to cover inline/template code

On Mon, 30 Apr 2012 11:07:51 +0200, RC (Ralf) wrote:


> >> 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.

My initial post contains a single question only:

What does the Packaging Committee think about the following?

I think that header-only library packages (where the ambiguous term
"library" could be substituted with "archive", "framework", "toolkit"
e.g.) should fall under the static library packaging guidelines. For the
same reasons those guidelines exist.

Trying to cover arbitrary header files in arbitrary packages would be
something different. Obviously, one needs to be very careful with regard
to publishing updates that touch the API.

> 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.).

Which I've commented on [briefly] in the bz ticket. Specifically, I called
it a "grey area". I can imagine scenarios such as compiling a program with
constant values defined in API headers, which change during an update and
affect the program's run-time behaviour. But I don't seek for the holy grail.
Hence a topic on header-only -devel packages.

> I.e. these packages inherit the bugs/changes these inlines/defines-only
> code fragments may contain and nobody will notice.

The same applies to static libs. Those are just _more_ special, because
fixes in a static lib haven't got any chance at all to affect statically
linked programs. This is what they have in common with header-only -devel
packages.

> 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.

Sure, but if all that matters is quantity, we could get rid of the static
lib guidelines, too.
http://mschwendt.fedorapeople.org/staticbugstat.html hasn't become
too long yet, but it could be that maintainers aren't notified properly
about updates to static libs.

Who cares if static lib packages follow the guidelines, if statically
linked apps get rebuilt _from time to time_ anyway? Hey, let's forget
about tracking static lib usage. Who cares about security-fixes in
static libs? Just kidding!

> In this context, my "where to draw the line" question was aiming at
> "when do you want a package to be treated specially?".

Okay, the answer to that is:

When changes in the packaged files are unable (!) to affect run-time
behaviour of existing dependencies.

> To exaggerate: Is adding a stub library to a "header only" package
> enough to exclude if from special treatment?

That's not the case I've asked about, and your personal goal of trying "to
draw a line" complicates matters in my opinion.
On the contrary, one goal of packaging guidelines is to give packagers a
hint on what to keep in mind when creating a package and during its
life-time.

> 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.

There are work-in-progress API/ABI checkers to help packagers, so
skimming over diffs is no the only thing that can be done.

> > Of course! There are C header-only libraries, too.
> I am not talking about "whole libraries". I am talking about individual
> files.

Well, I've asked about a header-only (library-less) -devel package.
Just a request for comments.

> AFAU, we don't handle this case at all, but trust in upstreams doing a
> reasonable job and in packagers doing so as well.

Which may have been an early answer to my initial question. ;-)

It could also be that handling header-only packages and static libs
could find a mention on the Package Maintainer Responsibilities page:
https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Notify_others_ of_changes_that_may_affect_their_packages

--
Fedora release 17 (Beefy Miracle) - Linux 3.3.4-1.fc17.x86_64
loadavg: 0.00 0.01 0.05
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging
 

Thread Tools




All times are GMT. The time now is 07:38 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org