On 04/27/2017 10:23 AM, Greg Freemyer wrote:
On Wed, Apr 26, 2017 at 7:32 PM, Simon Lees
wrote: On 04/27/2017 02:31 AM, Greg Freemyer wrote:
On Wed, Apr 26, 2017 at 2:40 AM, Dave Plater
wrote: <snip>
The safest way to distinguish leap versions is using %sle_version && %is_opensuse, openSUSE:Factory has %sle_version of 0 so you could use > for this. Dave P
Doesn't that imply that at some point in the next 18 months an effort should be made to remove all references in factory to %leap_version? They have no effect on factory/tumbleweed already and will have no effect in Leap Next (apparently Leap 15). f I have no idea what the sense of scale is to that effort. I'm not familiar with the osc command to grep all the spec files in factory.
Greg
Not necessarily, those packages may still be built and used by some people on Leap, as much as some don't like it people do use things from devel repo's with Leap and so they may as well stay until the maintainer decideds they don't want to support 42.X anymore. As an example of this many packages in devel:languages:python, still use conditionals / if branches to support SLE-11.
Keeping them doesn't hurt anything other then sometimes making spec files slightly harder to read in some cases, so really it comes down to when the maintainer decides to do a clean up of the spec file, for most I wouldn't expect that to happen until after 42.X goes end of life and to the other end I wouldn't be totally surprised if it was still in a package that doesn't change much in 10 years time (at that point i'd probably make some effort to remove it.
I understand Dave's statement to be %leap_version never had any unique value and the same decisions can be made based on other macros that aren't being deprecated.
If so and if it is being deprecated and never actually had any value add, why not make a proactive effort now to kill it off?
If it isn't defined in factory won't even be defined in Leap next, admit it was a mistake kill it now.
Because it is defined in current leap and there are a small number of cases in Leap 42.2 and 42.3 where it is required / makes sense to use it, most of that is for special conditions like additional patches / support that are needed in Leap 42.X but wont be needed in Leap 15. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B