On Tue, Apr 25, 2017 at 7:10 PM, Simon Lees wrote:

On 04/26/2017 08:00 AM, Greg Freemyer wrote:

...

I'm going to treat that as a given and I think that is all the board has spoken to so far.

But we have %suse_version, %sle_version, %leap_version, and %is_opensuse.

In Leap 42.2 they are:

suse_version = 1315 sle_version = 120200 leap_version = 420200 is_opensuse = 1

In Leap Next, if I understand correctly, we may kill off leap_version and only have:

suse_version = 1500 sle_version = 150000 is_opensuse = 1

Is it really all that painful to also have:

leap_version = 450000 or leap_version = 1500000 (note the extra zero)

And if having both sle_version and leap_version different really is that painful, why not make both 1500000

sle_version = 1500000 (with the extra zero) leap_version = 1500000 (with the extra zero)

Most uses i've seen using leap_version, are working around specific issues / patches for Leap 42.X as Leap 15.X will be branched freshly the number of cases where leap_version is applicable / still needed currently should be minimal, in most cases the current correct condition for Leap 15.X is still suse_version > 1320, and we will only need another conditional once 15.X has been branched properly and we need to distinguish between that and tumbleweed again for whatever reason.

Sounds like step 1 is going to be to go through all of OBS and eliminate use of leap_version. Almost none of the 100 or so packages I maintain for Leap are in SLE. The majority are in security:forensics. What's the osc command to cat out all the spec files in there so I can look for uses of leap_version? I may not even use it currently. Thanks Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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. -- 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

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