Proposal to reduce anti-bundling requirements

[Christopher]

Wouldn't the provides line needs a full path, otherwise, it could conflict?

I'm generally against this proposal. One of the reasons I like using a
distribution like Fedora is for dependency convergence. And I prefer
exceptions to be rare and carefully deliberated.

That said, where I think this could really help as a blanket policy change
is when it applies to bundled resources for web apps, like JavaScript
libraries. Those are often very hard to split out from the upstream build,
the web apps tend to rely on specific versions unique to that app, and
linking to a system-provided version tends to require drastic changes to
upstream code to change its resource-loading mechanisms.

[Apologies for top posting; on mobile]

On Thu, Sep 10, 2015, 09:53 Stephen Gallagher <sgallagh at redhat.com> 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."
>
>
>
> 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.
>
>
>
> 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.
>  * 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?
>
>
>
>
> Thank you for reading this far. I know that this is a topic that
> people get highly passionate about, so please do your best to restrain
> your responses to reasoned statments and avoid the temptation to get
> angry. I'll summon up a third of our Four Foundations here: remember
> that Fedora is built on "Friends" too. This should be a discussion and
> not an argument.--
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150911/96301c37/attachment.html>