Greetings all, I've just opened a ticket for the FPC to define what constitutes unbundling of a library: https://fedorahosted.org/fpc/ticket/19 I'm going to paste the question here for discussion so that the FPC doesn't make this decision in a vacuum. 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 so they aren't installed by the binary rpm. 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: https://bugzilla.redhat.com/show_bug.cgi?id=549405 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 when adding new code. 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 think that allowing option #2 or better makes sense (ie: making sure the bundled library never shows up on the filesystem at all would also be acceptable) but I'd like to hear other input. For instance, I'm willing to bet that some packages are doing #3 at the moment and would need to be further modified to also mark the libraries private. And I also wonder if anyone feels that #2 is not sufficient. Please speak up and tell me what you think. -Toshio ------------------------------------------------------------------------ -- packaging mailing list packaging(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging

On Tue, Oct 12, 2010 at 12:25:53PM -0500, Jon Ciesla wrote: > My understanding is that to completely unbundle a library, whether a > solib, a PHP lib, a Python module, whatever, you need to remove it from > the upstream tarball prior to the build (i.e. modified tarball, not a > patch or rm -rf in prep), > This part at least is not necessary. We only modify the upstream tarball when there's a reason that we can't ship the upstream source (which does coincide with bundling of some patent-encumbered media libraries.)

> and then use flags, symlinks, or whatever is > appropriate to use the system lib for building and running the program. > I don't feel like including the bundled version and making sure it's not > used is enough. You *can't* really make sure it's not used if it's present. > > <nod> This is the part I'd like us to discuss and decide. With pure python code, I can audit a particular release fairly confidently but in many cases, that doesn't provide protection when the next release is made (as upstream may have made a mistake when importing the compat library in their new code). Scons is an interesting case in that they've done a very good job of making it so that won't happen either. I'm not sure about whether that's possible for other languages and also whether we want to ignore the technical possibilities in order to make it easier to review -- ie: "Just delete the bundled versions and patch the source code so it runs" is easier to test if you're a non-programmer than "you don't have to delete the bundled version if certain other technical requirements for marking the library private are met of which both the reviewer and the packager would have to be knowledgable".

-Toshio ------------------------------------------------------------------------ -- packaging mailing list packaging(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging