On Wed, May 31, 2017 at 10:12 AM, Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
On Wed, 2017-05-31 at 06:50 -0400, Neal Gompa wrote:
Not that I don't appreciate the technical ingenuity that is involved in making these kinds of macros, but this feels like miles of bad road. It makes it really easy for people to do dumb patches and then just let them build up. And among other things, conditional patch application makes for builds with more "surprises" in them.
I also feel like this just makes it easier to not try to properly fix things. In my experience, most of the time, a proper fix for things like compiler/Qt issues typically don't break older compilers or Qt versions.
In general, I think we should be doing *way less* conditional patching, not more.
Then again, I'm not sure how much "working with upstream projects" is promoted in openSUSE compared to Fedora (where most of my packaging experience comes from).
Conditional patches certainly have to be the exception - but every so often you find upstream porting stuff to a new version of libFOO and just requiring it afterwards. Because they can.
We often build a package for multiple versions and try to care not only for 'newest' - just think about Leap, where a lot of things is not 'fresh of the press'
So if we have a pkg A that builds with libFOO in Leap, then in TW with get an update of libFOO+n and A's upstream simply ports to that API, without actually caring for backwards compatibility (and yes, those are many) - we can apply the UPSTREAM patch on our package without breaking the Leap build - because there we don't apply it.
Or... you know, just only develop to target Factory. The model you present makes it hard to enforce a factory-first model. When you are backporting from "the future" (as Factory is, relative to Leap/SLE), it makes sense to branch the package for "the past" (relative to Factory) and incorporate the patches that way. The back-and-forth is not sane.
And instead of quering the 'suse_version' as we did so far, we actually immediately gain the advantage that somebody building a branch somewhere with newer packages of libFOO added, the patch will be automatically applied.
(The example of course only holds true for libFOO being API incompatible to libFOO+n - and A's upstream simply dropping support for libFOO in favor of libFOO+n)
But it's still better than all the variants of %if %{suse_version} - where basically almost NEVER is the SUSE target version really the identifying factory for some change - so those macros help align the code to what the writer actually really wanted in first place (
It seems like this is being made more complicated than it should be. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org