Proposal to reduce anti-bundling requirements

[Adam Miller]

On Thu, Sep 10, 2015 at 10:43 AM, Adam Williamson
<adamwill at fedoraproject.org> wrote:
> 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?

AdamW brings up a good point about different rules for different
Rings, are the different Rings considered in the proposal at all?

-AdamM

> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
>
>
> --
> 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