'No bundling' policy details (was Re: F21 Self Contained Change: Playground repository)

[Adam Williamson]

On Tue, 2014-04-08 at 13:59 -0400, Stephen Gallagher wrote:
> On 04/08/2014 01:32 PM, Richard Shaw wrote:
> > On Tue, Apr 8, 2014 at 12:23 PM, Rex Dieter <rdieter at math.unl.edu 
> > <mailto:rdieter at math.unl.edu>> wrote:
> > 
> > Stephen Gallagher wrote:
> > 
> >> Ask yourself which is more important to most users: 1) My OS is
> >> perfectly maintainable by engineers. or 2) My OS lets me install
> >> the software I need without hassle.
> >> 
> >> Offering users a slightly-less stringent repository such as this
> >> makes sense.
> > 
> > Adding repos definitely should not be taken lightly.  Frankly, if 2
> > is really something worth doing, then perhaps also the (overly?)
> > stringent policies need rethinking.
> > 
> > I freely admit there's definitely some gray area here, and maybe
> > another repo is indeed the right (ie, least-bad) approach.
> > 
> > 
> > I agree. I'm working on several review requests from the same
> > developer that "bundle" the same code across his projects (an
> > xmlrpc implementation so each program can talk to each other). He
> > doesn't want to split it out into an independent library because he
> > doesn't want to support its use outside of his own programs, that
> > said I've been "working" with him to clean it up but it's a long
> > slow process and the software is perfectly usable as is.
> > 
> > It's probably not feasible, but If there was a way to track 
> > downloads/installs so I would know how many people are using the 
> > software it would give me an idea if it's worth the trouble to
> > "fix" the package to the guidelines or leave it in this
> > repository.
> 
> 
> In that specific case, my recommendation would be for him to have one
> of his packages create a subpackage that dropped that library in a
> non-system location (/usr/lib[64]/myproject-shared/mylib.foo) and then
> the other packages can link to that library directly.
> 
> Putting a library in a private location is a clear sign that other
> projects shouldn't attemp to use it (and that you make no claims
> whatsoever about its suitability for any other purpose).

Sorry for the thread necro, but I just wanted to point out that even
without Stephen's approach, I don't think the code in question violates
any policies. The policy against bundling reads as follows:

https://fedoraproject.org/wiki/Packaging:Guidelines#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."

At least as I read it, that prohibits the bundling of *previously
packaged, system-wide* shared resources. (The following text which
elaborates upon the guideline seems to confirm this, for me). I don't
believe it prohibits, nor is it intended to prohibit, the packaging of
*new* code along the lines described by Richard. Unless one of the
packages introduces the code as a system-wide library, and then the
other packages include their own 'bundled' copies of that library, I
don't think the packages in question would be against the guidelines.

It'd be interesting if you could link to the relevant review requests,
and anywhere someone has raised the contention that the bundling
guideline comes into play.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net