What exactly is a "bundled library"? (was Re: apitrace, bundled libbacktrace)

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

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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net