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: http://lists.freedesktop.org/archives/distributions/2008-September/000226.html 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. > -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
