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@xxxxxxxxxxxxxxxxxxxxxxx . 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
