'policy' for multiple versions of same software in EPEL

Toshio Kuratomi a.badger at gmail.com
Tue Oct 23 17:17:39 UTC 2012


On Tue, Oct 23, 2012 at 09:45:21AM -0500, Greg Swift wrote:
> On Mon, Oct 22, 2012 at 2:53 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> > As for non-upstream patches... we are against them but not as much as other
> > things. Non-upstream patches aren't a guideline in the Fedora packaging
> > guideline, for instance. Keeping non-upstream patches to a minimum allows
> > a package maintainer to do more work with their limited time.  But there are
> > things about packaging that sometimes require patching even if the upstream
> > won't accept them.  For instance, a patch to run against an older version of
> > a language even though the upstream doesn't care about that version anymore.
> > Figuring out how to utilize a different version of a library is just a short
> > step away from that.
> 
> Okay... I took its mention in the guidelines as more of a strong
> recommendation, especially due to the 'If you think that your package
> should be exempt from part of the Guidelines, please bring the issue
> to the Fedora Packaging Committee'.  Thanks for explaining that.
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment
> 
Ah -- yeah, that's a SHOULD guideline.  Shoulds are best practices that we
mention in the guidelines but it's a sign there's a lot more leeway as to
what's acceptable.  It usually means that there's good reasons to follow it
and good reasons not to.  When reviewing a package or looking at an existing
package there can be valid reasons that the spec file doesn't conform to
what the guideline says you should do.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20121023/4c41c0ba/attachment.sig>


More information about the epel-devel-list mailing list