Proposal to reduce anti-bundling requirements

[Adam Miller]

On Thu, Sep 10, 2015 at 10:04 AM, Peter Robinson <pbrobinson at gmail.com> wrote:
>>> > I would like to propose that the no-bundled-libraries policy be
>>> > amended  as follows: "Any package that has an existing mechanism to
>>> > link against a shared system library and functions correctly when
>>> > doing so must link against that library and not bundle it
>>> > internally.
>>> > Any package whose upstream releases cannot link against a shared
>>> > system library (or are incompatible with the version in Fedora) may
>>> > bundle that library (without requiring a special exemption) but
>>> > MUST
>>> > add Provides: bundled(<libname>) = <version> in the spec file for
>>> > each
>>> > known bundled library.(This will allow us to track down the
>>> > bundling
>>> > when we need to). Package maintainers should continue attempt to
>>> > engage upstream to support linking against shared system libraries
>>> > wherever possible, due to the advantages it provides the package
>>> > maintainer."
>>>
>>> Is <libname> the name of the SRPM which provides the system version
>>> of
>>> the library?
>>
>> Exact implementation TBD. I didn't want to get too far into the
>> technical details. Assume it to be a generally agreed-upon format.
>>
>>
>>>
>>> How do you propose to resolve symbol conflicts if both the system
>>> library and the bundled library are loaded into the same process?
>>>  The
>>> current ELF linking scheme lacks good support for bundling libraries
>>> whose exported symbols have not been mangled in some way.
>>>
>>
>> I expect such cases to be rare and dealt with on an as-needed basis.
>> Generally, projects either bundle or don't. The fuzzy area might be
>> with plugins, I guess.
>
> It doesn't matter how rare they are, it'll only take a single bundled
> library handled incorrectly to completely screw a running OS. I don't
> think this is something that can just be swept under the carpet, it
> needs to be addressed as a core part of the proposal and currently is
> not.
>

I was talking to someone at Red Hat Summit from the GCC/glibc team and
I was under the impression they (upstream) are working on something
that handles the symbol tables to allow parallel installed versions of
libs. No idea how far this is along but it's something that people are
working towards.

-AdamM

> Peter
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct