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.bad...@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
pgpGSOpNAR8xb.pgp
Description: PGP signature
_______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
