[Fedora-packaging] Proposal to reduce anti-bundling requirements

Haïkel hguemar at fedoraproject.org
Fri Sep 11 19:27:08 UTC 2015


2015-09-10 15:53 GMT+02:00 Stephen Gallagher <sgallagh at redhat.com>:
> 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."
>

Well, I won't discuss about benefits of unbundling vs bundling, this
is a sterile conversation.

I'll just point out that a non-negligible part of Fedora packages already
bundle libraries. Unless we want to mass-review and ban all those packages,
I consider that Stephen's proposal to be an *improvement* to the current
situation.

I would prefer that we also empower SIGs or provenpackagers to grant or not
those bundling exceptions and enforce the provides thing.

If you disagree, please come up with a counter-proposal even if it
means dropping half of Fedora packages.
Keeping status quo is at best diverting our eyes from bad practices,
at worst, hypocrite.

>
>
> 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.
> --
> packaging mailing list
> packaging at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/packaging


More information about the devel mailing list