#19 Treatment of bundled libraries
Closed: Fixed None Opened 11 years ago by toshio.

When we deal with bundled libraries there's some ambiguity as to what changes represent "unbundling". The changes may also differ between programming languages.

First the options that I see in descending order of intrusiveness into the package:

  1. Delete the bundled libraries from the binary rpm so they aren't installed (Note: this would probably never go upstream as is whereas the next two could.)
  2. Make sure that if bundled libraries are present in the final installed rpm that:
    1. They are not used by the rpm package
    2. They are marked private in some way so that they are not used by other rpm packages
  3. Make sure that if bundled libraries are present in the final installed rpm that they are not used by the rpm package

Here's a case in a python application that bundles but does so compliant to option #2

In this case, upstream is providing pieces of the python stdlib that may not be present on older versions of python. They mark the copied stdlib modules as private by prepending with a leading underscore. When run on a new enough python, the stdlib version of the module is imported rather than the bundled version. As a tangent, this upstream has set up importing of the modules so that they only have to make the check for stdlib modules in one place. Other upstreams I've seen have made the check each place that the module is imported which can lead to inadvertant use of the bundled module if they forget to make the check.

In the case of other languages, it depends on whether the languages provide a means of conditionally loading the bundled library vs the system library if present and if they provide a means of marking the bundled library private. For C libraries, for instance, I think this would require storing the module in a directory outside of the standard library path and also dlopening the bundled library if the program fails to dlopen the library from the standard library path. Writing this from scratch for C libraries and passing it to upstream is likely to be much more intrusive than writing something like the above python application does and hence less likely to be accepted by upstream. Upstream for C applications normally accept patches to choose the system library or bundled library at buildtime instead of runtime so doing the runtime detection also doesn't make as much sense there as for python.

I'll send email to the packaging list for feedback on this and we can discuss it in an fpc meeting afterwards.

Unbundling means removing them before compilation so nor package is linked against bundled library, neither package will use it after installation.

So I believe that

  • Every installation attempt of already existing library (even in some private directory) is clearly violates the "no bundled libraries" rule
  • Every building attempt when package is using whatever data from duplicate of already existed library is violation the "no bundled libraries" rule. No matter whether it just processes headers/private structures or explicitly links against.

I also believe that we may allow bundling library in the one and only possible case - when bundled library still not available in Fedora.

Discussion would be better on the packaging@lists.fp.o list. I'll copy and reply there.

This was talked about several meetings ago but fell off our radar -- Adding Meeting keyword so we remember to discuss and vote.

Announcement text:

A new page has been added which describes how to deal with bundled libraries when you find them in your package:


(it is queued up for today's announcement, so I'm closing this ticket.)

Metadata Update from @toshio:
- Issue assigned to spot

5 years ago

Login to comment on this ticket.