[Fedora-packaging] Use of Internal Libraries

[Nigel Jones]

On Thu, 2008-09-18 at 09:05 -0700, Toshio Kuratomi wrote:
> Nigel Jones wrote:
> > Hey guys,
> > 
> > So I know we have
> > http://fedoraproject.org/wiki/Packaging/Guidelines#Duplication_of_system_libraries which I think is pretty good, easy to understand and fairly simple.
> > 
> > The problem I think is that some upstream's still want to ship internal,
> > modified libraries.
> > 
> > Prime examples are mono packages, I can think of Banshee, Cowbell and
> > f-spot from personal experience.
> > 
> > It's got to point where another upstream is giving me a little bit of
> > hard time over it all, I even had a Debian developer agree with our
> > guidelines (they have the same).
> > 
> > Upstream says "it's a guideline not a rule".
> > 
> > _MY_ question is, what can we (Fedora) do to make it clear that we have
> > clear cut rules for why we don't want packages providing internal
> > libraries?
> > 
> 
> 1) We could rename the Guidelines to: Fedora Packaging Rules.
> 
> I know that many people like to say that the Guidelines really are
> Guidelines and that they can be broken for good reason but I'd much
> rather have them be strictly followed -- but make the process of
> granting provisional exceptions easier.
Maybe have two sets?  Fedora Packaging Principals - things that MUST NOT
be broken (think - do no harm, ensure patches go upstream, don't replace
system libraries in a package etc), and then the Fedora Packaging
Guidelines (where there can be a little bit of change due to special
circumstances (I can't remove rpath because the package just won't work
without it).
> 
> Having "MUST" rules that people can choose to disregard is silly.
> Remaining flexible about changing the rules when faced with areas that
> they don't live up to is the aspect that we want to retain, promote, and
> improve.
> 
> 2) Better organization.  Each rule should have a short form and link to
> a long form that explains the reasoning behind it.  This is something we
> need to take up with the docs team so we can figure out a better way to
> organize the rules.  CC'ing Karsten for this part.
Agreed
> 
> 3) I suspect that if your upstream is resorting to telling you, a Fedora
> Contributor, that the Fedora Guidelines are non-binding, then no matter
> what we do, he won't see reason.  We can do a better job of explaining
> it and we can get other distributions (which generally understand the
> reasoning here) to help put pressure on but at the end of the day the
> upstream author will either see the light or they won't.
> 
> One thing we could try in the distro-pressure regard is taking this up
> with the distributions group.  ##distro on irc.freenode.net,
> http://distribution.freedesktop.org, and
> http://lists.freedesktop.org/mailman/listinfo/distributions
> 
> Do people think that's a good way to go?  I'll send an email off to them
> if so.
I didn't know about the list, I think it'd be a good way to go, I know
Debian seem to agree with our policy, it'd be nice to create a united
front (in a way) to say to projects that it's unacceptable.

Really it all comes down to this:

If upstreams have a really good reason to change another upstreams code,
why haven't they submit it to their upstream?

It gets even more silly when upstreams act as upstream for other minor
libraries so that you get 5 or so copies floating about on your system
because everyone has had to fork it, because they've explicitly said to
maintainers to not package separately/as a subpackage. 

- NJ
-- 
Nigel Jones <dev at nigelj.com>