Proposal to reduce anti-bundling requirements

[Adam Williamson]

On Thu, 2015-09-10 at 09:53 -0400, Stephen Gallagher 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'm in no way a fan of the current wording of our policies here - it's
extremely vague and, as you say, subject to various interpretations.
It's also known (though perhaps not by all?) that we are nowhere
*close* to actually meeting the policy as written, most obviously in
the area of webapps: I think every webapp in the distro still bundles
Javascript. There is/was an effort to try and unbundle JS; the current
state of play seems to be nicely encapsulated in
https://fedoraproject.org/wiki/Changes/jQuery , which is an F23 change
to unbundle a *single javascript library*, which appears to be stalled
or at least behind (viz the cheerful "Coming Early July!" messages). I
know of (and in at least one case am the maintainer of) various other
packages which have code that's clearly 'bundled', under a strict
reading of the existing guidelines.

Writing a new policy is something that should be done very carefully,
though.

To me there is a clear ecosystem angle on this. What's appropriate for
the core ecosystem of stuff written in non-bundly languages (C,
Python, Perl...) is not necessarily appropriate for Web 2.0-ish things
written in bundly languages (PHP (oh god PHP), Go...)

To me this naturally ties in with the Fedora.next and 'rings' changes.
I'd suggest that a good direction to look in would be different
policies for different 'rings' (or however we wind up conceiving of
different areas of the distribution). I've argued before that it's
difficult to clearly delineate rings/layers of the distribution, but
it seems we are going to be trying to do so in some way, and so long
as that's going to happen, it seems natural to attach any change of
the bundling policy to that effort.

I'd also suggest that we might still want to forbid bundling of *some*
things in layers where it's otherwise permitted. Your policy, for
instance, would allow us to package something which bundles glibc, if
it does not have "an existing mechanism to link against a shared
system [copy]". Do we really want to allow bundling of the things
which *do* play by The Old Rules - the core infrastructure stuff which
is still, by and large, developed according to those conventions?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net