Proposal to reduce anti-bundling requirements

[Daniel P. Berrange]

On Thu, Sep 10, 2015 at 11:25:00AM -0400, Stephen Gallagher wrote:
> On Thu, 2015-09-10 at 16:04 +0100, Peter Robinson 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 think that's overstating the problem, Peter. Users are running
> hundreds of applications with bundled libraries today and are not
> obviously encountering this potential problem, which leads me to
> believe it's very uncommon and therefore not worth blocking progress
> on. Yes, it would be useful to have a plan in place for how to deal
> with it when it does happen. No, I don't think the plan has to be
> perfect before it can move forward.

Even if the problems did occur, the user is going to see it whether
they get the app from Fedora or from a 3rd party repo. I concur that
avoiding bundling is the most desirable scenario for apps in Fedora
but if that can't be achieved, a pragmatic approach benefits the users.
Chucking darktable out of Fedora due to bundling, isn't going to change
what users run. They will still run the exact same RPMs as they would
get from Fedora, but we'll have forced them to search out and enable
a copr / 3rd party repo. This hasn't helped users of darktable in any
way, just put an extra stumbling block in their way which will make
them less happy with the Fedora experiance overall :-(

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|