[Fedora-packaging] Proposal to reduce anti-bundling requirements

Adam Williamson adamwill at fedoraproject.org
Fri Sep 11 01:25:48 UTC 2015


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 at redhat.com> 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




More information about the devel mailing list