Hello,
On Wed, 23 Oct 2019, Stefan Seyfried wrote:
I chose to believe it's just lack of information from your side and you are not mocking us deliberately. The reality is that I tried to fix build issues with older SLE releases or revert "cleanup" changes which broke the build. Most of the time, the response was like "No, we won't clutter our precious specfile just for compatibility with products which are long dead." (Where "long dead" often meant products still in regular support phase.) Eventually, I gave up and keep forks of packages I care about most in my home project. I'm pretty sure I'm not the only one with similar experience and resolution.
What I really like is the fedora "epel-rpm-macros"-style way of just adding backwards compatibility via clever (even is sometimes "ugly" looking) rpm macro / config tricks.
Maybe we can come up with similar "add on config"-RPMS that can be additionally added to older buildroots in prjconf to make life easier.
While I do see the value in this, there's one other thing to consider: some of our packages are actually not merely building for old distros for our convenience, but rather with the intention of them actually getting into the old SLE trees themself. For these such hackery would be harmful: you believer everything is fine and dandy because it builds in your own repo for old distros just fine, but then when the time comes to submit it to SLE-12:GA you go "aw crap, need to fix all these errors" ;-)
So, yeah, Richis idea of backporting new macros to old SLE trees has some merit (though of course this might bring its own problems which might not be wanted in those trees). Until then we'll have to reject (or revert) some of the changes, especially if they aren't making the world that much better.
Ciao, Michael.