Proposal to reduce anti-bundling requirements

[Stephen Gallagher]

On Thu, 2015-09-10 at 10:08 -0400, Josh Boyer wrote:
> On Thu, Sep 10, 2015 at 9:53 AM, Stephen Gallagher <sgallagh at redhat.c
> om> wrote:
> > I assume that subject line got your attention.
> > 
> > I know this is a long-standing debate and that this thread is
> > likely
> > to turn into an incomprehensible flamewar filled with the same
> > tired
> > arguments, but I'm going to make a proposal and then attempt to
> > respond to many of those known arguments up-front (in the hopes
> > that
> > we can try to keep the conversation on-track). Please keep the
> > conversation on devel at lists.fedoraproject.org . I CCed packaging@
> > to
> > make them aware of this discussion.
> > 
> > 
> > 
> > Right now, we have a policy that essentially forbids source code
> > from
> > being bundled into a package. In technical terms, this means
> > essentially that the packaging policies mandate that any code that
> > appears more than once in the repository must be turned into a
> > shared
> > library and dynamically linked into any package that requires it.
> > Any
> > package that wants an exception to this must petition the Fedora
> > Packaging Committee and get an explicit exemption from this policy.
> > This process is heavyweight and sometimes inconsistent in how the
> > decision is made.
> > 
> > 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."
> 
> This seeks to amend the proposal for bundling within a SRPM itself.
> It doesn't address the broader scope of delivering applications
> outside of RPM, such as Docker containers or xdg-apps.  Those also
> tend to bundle, but the bundling is done within the container.  In
> the
> case of xdg-apps, they'll need to "bundle" anything that isn't
> provided by the xdg-runtime.
> 
> Do you want to address the broader issue, or do you foresee that the
> current Packaging guidelines simply won't apply to containerized apps
> because they are too RPM specific?
> 

This proposal was specifically about RPM/SRPM bundling. I think the
broader issue may be impacted by any decision we make here (if we
allow RPM bundling then by definition bundling has precedent). I'd
prefer to keep the container/xdg/etc. discussion out of this thread
for fear of making the conversation too broad.


> > The reason for this proposal is relatively simple: we know the
> > advantages to unbundling, particularly with security and resource-
> > usage. However, the world's developer community largely *does not
> > care*. We fought the good fight, we tried to bring people around to
> > seeing our reasoning and we failed.
> > 
> > 
> > The point of software is to provide a service to an end-user. Users
> > don't run software because it has good packaging policies, they run
> > software because it meets a need that they have. If they can't get
> > that software from Fedora, they *will* get it from another source
> > (or
> > use a different OS that doesn't get in their way). I'll take a
> > moment
> > to remind people that two of Fedora's Four Foundations are
> > "Features"
> > and "First". We want Fedora to be the most feature-complete
> > distribution available and we want to get there before anyone else
> > does. I would say that holding to our no-bundling policy actively
> > defeats our efforts on that score.
> 
> Is the intention of your proposal to also allow Chromium into the
> main
> Fedora repos?  I honestly can't tell where it draws the line.
> 

I can't remember the specific issues around Chromium, so I don't
necessarily want to say yea or nay there. I *thought* I remembered
Chromium had issues beyond simple bundling though. If not, then I see
no problems with including it if this proposal passes.


> > Let me describe some of the advantages to bundling and to
> > unbundling
> > (as noted so we can hopefully skip some of the hotter parts of the
> > flamewar). As I noted above, anything that is capable of unbundling
> > should remain unbundled for its advantages. But things that are not
> > currently capable (or can't be due to forwards/backwards
> > compatibility
> > issues, etc.) really shouldn't be forced to attempt it.
> > 
> > 
> > == Advantages to using shared libraries ==
> >  * Security/Bugs - When a bug or security vulnerability is located
> > in
> > a library, it needs to be patched in only a single package in
> > order to
> > fix all applications using that library.
> 
> I think it's worth expanding on this a bit.  Right now, the Security
> team files bugs against the main instance of a library/package.  The
> proposal seems to help mark bundled copies, but it will still require
> more time for them to file bugs against packages that bundle.
> 

Yes, you're absolutely right. I think we can work on some automation
for that, but at the end of the day it *will* mean a bit more process
during those cases. I'd need to hear from the security team whether
this would likely be frequent enough to be a real problem or only a
minor inconvenience.


> >  * Resources - A shared library only needs to be loaded into memory
> > once, reducing the memory requirements of the system.
> > 
> > == Advantages to bundling ==
> >  * Guarantees that the application is running with the same set of
> > code that upstream tested. (Fewer Fedora-specific bugs means less
> > burden on the maintainer)
> >  * Simplifies packaging of updates. (Fedora maintainer does not
> > need
> > to keep tabs on unbundling patches to keep in sync for new
> > versions)
> >  * Increases the available pool of software that can be packaged
> > substantially (many modern languages such as Ruby and Go are
> > realistically only functional with allowable bundling)
> >  * Did I mention the reduction in maintainer burden yet?
> 
> Going back to security, would you expect Fedora maintainers to patch
> the bundled copy of the code to fix issues?  I'm curious if that will
> break some of upstream's assumptions, etc.
> 

Well, my first recommendation would be for them to push security
patches simultaneously to upstream. It's not like the patches won't be
useful to upstream's community.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150910/6c68f704/attachment.sig>