On Thu, 2015-09-10 at 18:13 -0700, Adam Williamson wrote: > On Thu, 2015-09-10 at 20:04 -0500, Jason L Tibbitts III wrote: > > > > > > > "AW" == Adam Williamson <awilliam@xxxxxxxxxx> writes: > > > > AW> I think the fact that we can't even have a discussion of this > > where > > AW> we both understand what the current rules actually *are* > > clearly > > AW> indicates they have a clarity problem =) > > > > You may recall my earlier message in this thread where I indicated > > that > > I believe that at the very least we need to clarify the language. > > Sure, I wasn't saying we disagree. But obviously in order to continue > discussing this we need to have some kind of agreement on what the > current rules actually *are*. > > So could you clarify what you meant by 'compiled in'? What would be a > case which (in your interpretation) FPC 'cares about' vs. one it > doesn't? Just to add to the confusion - now I look at the guidelines again, there's a *second* section which appears to be talking about bundling. So we have both this text: +++++++++++++++++++++ == Duplication of system libraries == A package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries. This prevents old bugs and security holes from living on after the core system libraries have been fixed. In this RPM packaging context, the definition of the term 'library' includes: compiled third party source code resulting in shared or static linkable files, interpreted third party source code such as Python, PHP and others. At this time JavaScript intended to be served to a web browser on another computer is specifically exempted from this but this will likely change in the future. Note that for C and C++ there's only one "system" in Fedora but for some other languages we have parallel stacks. For instance, python, python3, jython, and pypy are all implementations of the python language but they are separate interpreters with slightly different implementations of the language. Each stack is considered its own "system" and can each contain its own copy of a library. Some packages may be granted an exception to this. Please see the No Bundled Libraries page for rationale, the process for being granted an exception, and the requirements if your package is bundling. +++++++++++++++++++++++ and this text: +++++++++++++++++++++++ == Bundling of multiple projects == Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package. However, when this is unavoidable, packagers must apply for a Bundling Exception with the Fedora Packaging Committee. For more information on Bundling and applying for a Bundling Exception, please read Packaging:No_Bundled_Libraries. ++++++++++++++++++++++ To me how these two guidelines interact and what they're actually intended to cover seems very unclear. Given the existence of both, I can see the interpretation (which I guess is what Jason means?) that the second applies to this kind of case: fedorapackage.spec Source0: http://www.project.com/project1-1.0.0.tar.gz Source1: http://completely-different-project.com/other-project-2.0.3.tar.gz Which, I mean, sure, it's reasonable to cover that specific case, I guess. But the guideline doesn't really clearly restrict itself to that case - in what sense is a package of a tarball from project.com that bundles a library from completely-different-project.com *not* a case of "having multiple, separate, upstream projects bundled together in a single package"? The fact that this paragraph too explicitly refers to the 'No Bundled Libraries' page for exceptions only increases the likelihood of it being taken as relevant to 'bundling', as we talk about it here. So I can see two fairly radically different readings of the guidelines as they stand, depending on whether 'Bundling of multiple projects' is intended to cover *upstream* bundling or not. Assuming it isn't, maybe a simple, non-controversial first step in clarification would be to revise 'Bundling of multiple projects' to be clearer that it is covering the case of *downstream* bundling only? I'll note that if we consider only the *first* paragraph to cover upstream bundling, then to me it seems that it can only possibly be read as forbidding bundling of libraries *that are already packaged downstream* - and hence it can't reasonably be read as applying to rawspeed, to circle back to the specific case that started this whole kerfuffle. It explicitly refers to "a library that exists on a system. The package should be patched to use the system libraries." rawspeed clearly doesn't meet that test, for me: it's *never* been intended to be a 'system library', nor has Fedora ever included it as one. -- 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
