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