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
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org