Proposal to reduce anti-bundling requirements

[Peter Robinson]

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

Peter