[Fedora-packaging] Use of Internal Libraries

Toshio Kuratomi a.badger at gmail.com
Fri Sep 19 03:29:51 UTC 2008

Nigel Jones wrote:
> 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.

Message sent:

Anyone interested, feel free to contribute to the thread that will
likely result.  if this is seen as a good thing, we'll probably want to
start documenting our justifications for doing this on the
distributions.freedesktop.org wiki.

> 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. 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-packaging/attachments/20080918/fce14c0a/attachment.sig>

More information about the Fedora-packaging mailing list