On Thu, Sep 10, 2015 at 8:53 AM, Stephen Gallagher <sgallagh(a)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(a)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