Toshio Kuratomi wrote: > 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/packaging 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), 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. In essence, if it's not #1, you're not really un-bundling. My $0.02. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
