On Thu, 11 Jun 2015, Stephan Kulow wrote:
On 11.06.2015 11:22, Richard Biener wrote:
On Thu, 11 Jun 2015, Jan Engelhardt wrote:
[you guys can stop CCing me, I'm subscribed :]
On Thursday 2015-06-11 11:03, Richard Biener wrote:
Yes. Please make sure %suse_version is sensible for openSUSE 42 then (like using the value from SLE12). Not 4200 please ;)
This proposal _has_ to be rejected. It will break about every other package that uses %suse_version <=1320 / >1320.
What is worse is that due to absence of %sles_version since SLE12, we now have to special-case versions 1110 and 1315, as in, exemplary:
%if 0%{?suse_version} != 1110 && 0%{?suse_version} != 1315 BuildRequires: libgsasl-devel %endif ... %configure \ %if 0%{?suse_version} != 1110 && 0%{?suse_version} != 1315 --enable-gsasl %endif
Yes, something I'd like to avoid...
The problem is that packages using %suse_version > 1320 might actually be broken on :42 - SLE12's sources are different than what we had when this was done.
So I'm afraid there is no good solution - suse_version must die ;(
Well... For my particular case a required %define in the project config like %macros %libstdcxx_abi_version 98 (or 11 for the c++11 version) would of course work. Or some other means of injecting such, like having a rpm-branding package that amends /usr/lib/rpm/macros (or even /etc/rpm.d/*) The issue is usually that you only figure out you need sth like that when older trees "break" with new package versions, so you can't really fixup the thing in the old system properly. Thus you'd need to be conservative by default and via some means like the above "enable" the yes-we-are-new-enough path.
But knowing what strange uses we have for "1315" I'm afraid to touch it. So I would actually go with "%suse_version 1315" and "%opensuse_version 42" and increase suse_version in TW every month or so.
I think keeping %suse_version at 1315 is the only sensible way. Not sure
why you need %opensuse_version thoguh. If %suse_version has to die
the solution can't be to add %opensuse_version ;)
Instead the solution is to adopt some (policy) about configuring
package builds via the project config or similar means.
Richard.
--
Richard Biener