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

[Adam Miller]

On Thu, Sep 10, 2015 at 8:53 AM, 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.
<SNIP>

(Reluctantly) +1

We fought the good fight for a very long time but I agree that the
greater upstream developer communities at large just don't care. I
also like the proposal for the bundled(<libname>) macro definition for
tracking purposes.

I'm generally in the "fight the good fight for shared libs" camp but I
think we're at a turning point where ideology needs to meet in the
middle with reality.

Thank you for the thoughtful write up and for taking on the task of
the debate that is to come. :)

-AdamM