Neal Gompa wrote:
> While that is true, *I* don't like doing that if I don't have to. I'd
> rather try to get things fixed upstream in tandem. Upstreams tend to
> appreciate that in my experience. :)
Sure, but it tends to be significantly more work. Upstreams need to support
several platforms at once, so they often cannot just move to new libraries
and drop support for the old ones, and some are also quite picky about code
style issues that ultimately do not matter to end users.
> (This is probably why so many people think I'm everywhere, to be honest!
> :P )
:-)
> Further analysis indicates that dvdauthor has a patch in openSUSE[2],
> but the fix breaks support for GraphicsMagick as an alternative. I
> want to rework that patch so it doesn't break GraphicsMagick and old
> ImageMagick support so that it's suitable for upstreaming. I don't
> expect this to be too difficult to do.
Well, that is exactly why it is harder to make a patch that is acceptable to
upstream than one that works in the distribution. A downstream patch can
even be conditionally applied, if you want to support old and new library
versions in the same specfile, so the dual support need not be in the patch.
This is of course not the case for an upstream patch. So then you end up not
only adding "#ifdef"s for every line you changed, but also need to add a
build system ("configure") check for the library version. It can turn a
quick search&replace job into a patch adding dozens of new lines of code.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
