On 13.05.2014 19:02, Jakub Jelinek wrote:

On Tue, May 13, 2014 at 06:56:40PM +0200, Sandro Mani wrote:

...

apitrace 5.0 bundles libbacktrace, which looks like is living within the gcc sources. libbacktrace is not build as a shared library from the gcc sources, and not packaged.

Is it feasible to build libbacktrace as a shared library and ship it in a corresponding package?

No.

...

Or should I rather go for a bundling exception request?

I'd say so.

Ok thanks. While I'm at it, looks like apitrace is using GLIBC_PRIVATE symbols... How can I find out which are the offending symbols?

Thanks, Sandro

On Tue, 2014-05-13 at 18:56 +0200, Sandro Mani wrote:

Hi,

apitrace 5.0 bundles libbacktrace, which looks like is living within the gcc sources. libbacktrace is not build as a shared library from the gcc sources, and not packaged.

Is it feasible to build libbacktrace as a shared library and ship it in a corresponding package? Or should I rather go for a bundling exception request?

So in writing a reply to this, I noticed the guidelines around this are actually fairly unclear and subject to interpretation.

The section on this topic from https://fedoraproject.org/wiki/Packaging:Guidelines reads:

"Duplication of system libraries

A package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries. This prevents old bugs and security holes from living on after the core system libraries have been fixed.

In this RPM packaging context, the definition of the term 'library' includes: compiled third party source code resulting in shared or static linkable files, interpreted third party source code such as Python, PHP and others. At this time JavaScript intended to be served to a web browser on another computer is specifically exempted from this but this will likely change in the future.

Note that for C and C++ there's only one "system" in Fedora but for some other languages we have parallel stacks. For instance, python, python3, jython, and pypy are all implementations of the python language but they are separate interpreters with slightly different implementations of the language. Each stack is considered its own "system" and can each contain its own copy of a library."

The thing that is particularly unclear there is the definition of "a system" (as in "a library that exists on a system"). The following paragraphs seem to imply that Fedora's stacks for languages/frameworks that implement some kind of shared library functionality are to be understood as "systems" in that context. This is still not made *entirely* clear, though, really.

The page https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries has all sorts of rationale and process stuff, but still no clear definition of precisely what it is that constitutes a "bundled library".

Even more confusingly, https://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries seems to have a rather different definition from that given on Packaging:Guidelines. It reads:

"(bundled libraries being defined as libraries which exist and are mantained independently, whether or not they are packaged separately for Fedora)"

to me, that seems fundamentally different from the definition that is somewhat unclearly implied on the Packaging:Guidelines page.

Has this been considered before? Is there a superior definition somewhere, or an accepted interpretation which is consistent with both pages?

Do we in fact need a section in Packaging:Guidelines and then two separate 'subsidiary' pages all on the topic of bundled libraries? Would it make more sense to combine all the details onto a single subsidiary page and have Packaging:Guidelines just have a very short sort of 'summary' and a link to that one subsidiary page? Would that reduce the likelihood of confusion?

Thanks!

I've seen several cases in the Real World where 'bundled' libraries that are not a part of the Fedora repositories were considered to be OK under the policy, which is a possible interpretation of the policy as given on Packaging:Guidelines, but doesn't really seem to be a possible interpretation of the policy as given on Packaging:Treatment_Of_Bundled_Libraries (as it explicitly states "whether or not they are packaged separately for Fedora"). This could have considerable implementations for webapps if it were interpreted strictly, I think.

On Tue, 2014-08-19 at 15:19 +0400, Pavel Alexeev wrote:

13.06.2014 01:42, Adam Williamson пишет:

...

On Tue, 2014-05-13 at 18:56 +0200, Sandro Mani wrote:

...

Hi,

apitrace 5.0 bundles libbacktrace, which looks like is living within the gcc sources. libbacktrace is not build as a shared library from the gcc sources, and not packaged.

Is it feasible to build libbacktrace as a shared library and ship it in a corresponding package? Or should I rather go for a bundling exception request?

So in writing a reply to this, I noticed the guidelines around this are actually fairly unclear and subject to interpretation.

The section on this topic from https://fedoraproject.org/wiki/Packaging:Guidelines reads:

"Duplication of system libraries

A package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries. This prevents old bugs and security holes from living on after the core system libraries have been fixed.

In this RPM packaging context, the definition of the term 'library' includes: compiled third party source code resulting in shared or static linkable files, interpreted third party source code such as Python, PHP and others. At this time JavaScript intended to be served to a web browser on another computer is specifically exempted from this but this will likely change in the future.

Note that for C and C++ there's only one "system" in Fedora but for some other languages we have parallel stacks. For instance, python, python3, jython, and pypy are all implementations of the python language but they are separate interpreters with slightly different implementations of the language. Each stack is considered its own "system" and can each contain its own copy of a library."

*entirely* clear, though, really.

The page https://fedoraproject.org/wiki/Packaging :No_Bundled_Libraries has all sorts of rationale and process stuff, but still no clear definition of precisely what it is that constitutes a "bundled library".

Even more confusingly, https://fedoraproject.org/wiki/Packaging :Treatment_Of_Bundled_Libraries seems to have a rather different definition from that given on Packaging:Guidelines. It reads:

"(bundled libraries being defined as libraries which exist and are mantained independently, whether or not they are packaged separately for Fedora)"

to me, that seems fundamentally different from the definition that is somewhat unclearly implied on the Packaging:Guidelines page.

Has this been considered before? Is there a superior definition somewhere, or an accepted interpretation which is consistent with both pages?

Do we in fact need a section in Packaging:Guidelines and then two separate 'subsidiary' pages all on the topic of bundled libraries? Would it make more sense to combine all the details onto a single subsidiary page and have Packaging:Guidelines just have a very short sort of 'summary' and a link to that one subsidiary page? Would that reduce the likelihood of confusion?

Thanks!

I've seen several cases in the Real World where 'bundled' libraries that are not a part of the Fedora repositories were considered to be OK under the policy, which is a possible interpretation of the policy as given on Packaging:Guidelines, but doesn't really seem to be a possible interpretation of the policy as given on Packaging:Treatment_Of_Bundled_Libraries (as it explicitly states "whether or not they are packaged separately for Fedora"). This could have considerable implementations for webapps if it were interpreted strictly, I think.

Sorry for the old thread. But it is very interesting question to clearly determine "bundled library" to which returning happened again and again. Does it hang again now or something indeed changed?

Yeah, I'm still interested in other people's thoughts on this, I rather expected it to get more traction when first posted. I guess I'll try one more bump (this one) and if still no-one bites, we can file an FPC ticket, perhaps.

On 2015-01-08, 03:36 GMT, Richard Shaw wrote:

In the specific case I ran into one of the package suites I've been working on technically bundles a modified copy of xmlrpcpp. However, it is quite modified, upstream is dead, it's not already in Fedora, and the author I'm working with only uses it for communication between his suite of programs and has no intention of offering it as a separate library.

Hi,

I think in the end it is not that much matter of definition as where the buck stops. I believe there are these questions which need to be answered:

1) Will you be able to identify a security concern? Way more simple for the independent well-known library, then for some directory down in your project. Even more difficult for hundreds of bundled libraries scattered all over the system (the famous Debian libz issue). 2) Who will fix the issue? Because if there is not well maintained upstream for the library, or if the maintainer of your upstream is not willing or able to fix any issue which comes her way, then there is only person who is responsible for fixing any such issue, you.

Best,

Matěj