On Tue, Apr 25, 2017 at 5:54 PM, Simon Lees sflees@suse.de wrote:
On 04/25/2017 11:57 PM, Rüdiger Meier wrote:
On 04/25/2017 04:11 PM, Simon Lees wrote:
On 04/25/2017 11:30 PM, Simon Lees wrote:
On 04/25/2017 10:44 PM, Rüdiger Meier wrote:
On 04/25/2017 03:05 PM, Greg Freemyer wrote:
On Tue, Apr 25, 2017 at 8:53 AM, Stefan Seyfried stefan.seyfried@googlemail.com wrote: > On 25.04.2017 14:26, Christian Boltz wrote: >> So even without the 42.x -> 15.x leap (pun intended), it seems >> version >> numbers are already confusing ;-) I know switching to 15.x adds >> slightly more confusion now, but on the long term it's much >> better to >> have SLE, Leap and suse_version in sync than always having to do >> the "+ >> 30" math for the Leap version. > > As I already mentioned, we could just go for 150, 151, 152, 160... > > This would still be tied to SLES in an obvious way, and not backwards > from 42.x > > Best of both worlds.
At a minimum that should be done in /etc/issue.
And maybe %leap_version 1500000, 1510000, 1520000, 1600000, ... in rpm macros.
I still don't get why do we need to be tied to SLES version numbers at all. What is the technical reason behind this? It is pure unimportant cosmetics.
Well the two distro's share a significant number of source packages that are the same so being able to refer to them in the same way in places makes a reasonable amount of sense.
That's true and it's *nice* to know, not more. There is no technical reason why /etc/os-release should have the same VERSION_ID on LEAP and SLE.
The following shows us that around 1890 of the 9296 packages in Leap 42.2 come directly from the SLE equivalent, most of these packages are core parts of the distro, think systemd, dbus, gtk, qt etc. So from a technical perspective being able to version them the same certainly has advantages.
simon@tek-top ~ ➤ osc -A https://api.opensuse.org cat openSUSE:Leap:42.2:Update 00Meta lookup.yml | wc -l 9296 simon@tek-top ~ ➤ osc -A https://api.opensuse.org cat openSUSE:Leap:42.2:Update 00Meta lookup.yml | grep "SLE-12" | wc -l 1890
And...? You mean you could have done this task easier on Leap 15 as it's planned?
No, Obviously you've found out this although 42.2 is different from the SLE version. You did not even used "SP2", probably you could have also grepped without "12".
No, I'm not referring to this specific task, but i'm showing 1890 places where there is a technical reason to use the same version between the two as we share the code between the two.
I'm just talking rpm macros exclusively below, so nothing visible to the public or 99% of users:
I don't think any of the negative comments I've heard are complaining about %suse_version being 1500 for the next major Leap release (after 42.3).
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)
There are no existing spec files that are testing for %sle_version == 150000, so just add a zero and the spec files get to as simple as possible from day 1 of SLE 15 development. (which I assume is very soon).
Greg
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.
On Tue, Apr 25, 2017 at 7:10 PM, Simon Lees sflees@suse.de 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
On 04/26/2017 09:08 AM, Greg Freemyer wrote:
On Tue, Apr 25, 2017 at 7:10 PM, Simon Lees sflees@suse.de 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.
I don't remember the specific command but as long as the packages also build for tumbleweed where we don't have it set you won't need to do anything, once Leap 42.X is out of support (remembering we still have a release to go), then you may choose to go through and clean up the dead code but it won't cause any issues keeping the conditions there as long as those conditions are specific to leap.
On 26/04/2017 00:30, Greg Freemyer wrote:
I'm just talking rpm macros exclusively below, so nothing visible to the public or 99% of users:
I don't think any of the negative comments I've heard are complaining about %suse_version being 1500 for the next major Leap release (after 42.3).
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)
There are no existing spec files that are testing for %sle_version == 150000, so just add a zero and the spec files get to as simple as possible from day 1 of SLE 15 development. (which I assume is very soon).
Greg
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
On Wed, Apr 26, 2017 at 2:40 AM, Dave Plater dplater.list@gmail.com 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).
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
On 04/27/2017 02:31 AM, Greg Freemyer wrote:
On Wed, Apr 26, 2017 at 2:40 AM, Dave Plater dplater.list@gmail.com 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.
On Wed, Apr 26, 2017 at 7:32 PM, Simon Lees sflees@suse.de wrote:
On 04/27/2017 02:31 AM, Greg Freemyer wrote:
On Wed, Apr 26, 2017 at 2:40 AM, Dave Plater dplater.list@gmail.com 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.
A good script writer could probably do it in a few hours and then no one ever has to think about it again.
Greg
On 04/27/2017 10:23 AM, Greg Freemyer wrote:
On Wed, Apr 26, 2017 at 7:32 PM, Simon Lees sflees@suse.de wrote:
On 04/27/2017 02:31 AM, Greg Freemyer wrote:
On Wed, Apr 26, 2017 at 2:40 AM, Dave Plater dplater.list@gmail.com 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.
-
Dave Plater -
Greg Freemyer -
Simon Lees