'No bundling' policy details (was Re: F21 Self Contained Change: Playground repository)
hobbes1069 at gmail.com
Thu May 8 19:43:16 UTC 2014
On Thu, May 8, 2014 at 2:38 PM, Adam Williamson <awilliam at redhat.com> wrote:
> 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/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:
> "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
> 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.
Thank you. That makes sense to me. If he was just bundling the system
xmlrpcpp then we would need to do something about it, but it's heavily
modified and upstream seems to be dead anyhow.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel