On 23 April 2017 at 10:55, Matwey V. Kornilov matwey.kornilov@gmail.com wrote:
22.04.2017 14:37, Richard Brown пишет:
Hi all,
On behalf of the openSUSE Board and Leap Release Management I am pleased to announce the next version of openSUSE Leap after 42.3 will be:
openSUSE Leap 15
What version will be after openSUSE Leap 41?
Leap and SLE major versions come out on average about once every 4 years.
So with this plan, starting at openSUSE Leap 15 in 2018, Leap 41 should be 104 years away
Ask this question again in 2122 and we'll figure out the answer then.
Am 23.04.2017 um 11:15 schrieb Richard Brown:
Leap and SLE major versions come out on average about once every 4 years.
So with this plan, starting at openSUSE Leap 15 in 2018, Leap 41 should be 104 years away
You are assuming everything stays as-is for the next 100 Years. But yes, a few more stunts like this and you won't have to worry about too many new versions.
Even though I have to admit, that it probably makes sense to align with SLES, it shows again how stupid the whole "LEAP 42.1" thing was.
... the most annoying part of it btw being the overly long OBS project names: $ osc r openSUSE_Tumbleweed i586 succeeded openSUSE_Tumbleweed x86_64 succeeded openSUSE_Leap_42.2 x86_64 succeeded openSUSE_Leap_42.1 x86_64 succeeded openSUSE_13.2 x86_64 failed
even for 13.2 that's at least 9 redundant characters, but for 42.1/2/3 it's 14 and for Factory it's 12.
On 23 April 2017 at 11:36, Stefan Seyfried stefan.seyfried@googlemail.com wrote:
Am 23.04.2017 um 11:15 schrieb Richard Brown:
Leap and SLE major versions come out on average about once every 4 years.
So with this plan, starting at openSUSE Leap 15 in 2018, Leap 41 should be 104 years away
You are assuming everything stays as-is for the next 100 Years. But yes, a few more stunts like this and you won't have to worry about too many new versions.
Even though I have to admit, that it probably makes sense to align with SLES, it shows again how stupid the whole "LEAP 42.1" thing was.
... the most annoying part of it btw being the overly long OBS project names: $ osc r openSUSE_Tumbleweed i586 succeeded openSUSE_Tumbleweed x86_64 succeeded openSUSE_Leap_42.2 x86_64 succeeded openSUSE_Leap_42.1 x86_64 succeeded openSUSE_13.2 x86_64 failed
even for 13.2 that's at least 9 redundant characters, but for 42.1/2/3 it's 14 and for Factory it's 12.
I wouldn't be opposed to the removal of 'openSUSE_' from the build target names for Leap and Tumbleweed.
On 04/23/2017 07:09 PM, Richard Brown wrote:
On 23 April 2017 at 11:36, Stefan Seyfried stefan.seyfried@googlemail.com wrote:
Am 23.04.2017 um 11:15 schrieb Richard Brown:
Leap and SLE major versions come out on average about once every 4 years.
So with this plan, starting at openSUSE Leap 15 in 2018, Leap 41 should be 104 years away
You are assuming everything stays as-is for the next 100 Years. But yes, a few more stunts like this and you won't have to worry about too many new versions.
Even though I have to admit, that it probably makes sense to align with SLES, it shows again how stupid the whole "LEAP 42.1" thing was.
... the most annoying part of it btw being the overly long OBS project names: $ osc r openSUSE_Tumbleweed i586 succeeded openSUSE_Tumbleweed x86_64 succeeded openSUSE_Leap_42.2 x86_64 succeeded openSUSE_Leap_42.1 x86_64 succeeded openSUSE_13.2 x86_64 failed
even for 13.2 that's at least 9 redundant characters, but for 42.1/2/3 it's 14 and for Factory it's 12.
I wouldn't be opposed to the removal of 'openSUSE_' from the build target names for Leap and Tumbleweed.
I think thats reasonable although the only place outside ports I see issues is here http://www.enlightenment.org/ss/e-58fc8d0753ed70.80167372.jpg , Having said that I think to do this we would need to go through and change each repositories meta 1 by 1. Although Repository maintainers could already make this change. You may even choose to prepend # to Tumbleweed and * to Leap so that Tumbleweed shows up first followed by Leap as seen here in this test repo http://www.enlightenment.org/ss/e-58fc8e94546eb9.18281392.jpg (I guess i now need to pass silly names to osc build).
On Sunday 2017-04-23 11:39, Richard Brown wrote:
$ osc r openSUSE_Tumbleweed i586 succeeded openSUSE_Tumbleweed x86_64 succeeded openSUSE_Leap_42.2 x86_64 succeeded openSUSE_Leap_42.1 x86_64 succeeded openSUSE_13.2 x86_64 failed
even for 13.2 that's at least 9 redundant characters, but for 42.1/2/3 it's 14 and for Factory it's 12.
I wouldn't be opposed to the removal of 'openSUSE_' from the build target names for Leap and Tumbleweed.
Are there no pressing issues really? How about the Factory vs Tumbleweed problem is solved first..
Fancy this:
osc rbl devel:project/package openSUSE_Leap_42.2 x86_64
works almost anytime, but whether you need
osc rbl d:p/p openSUSE_Tumbleweed x86_64 (or) osc rbl d:p/p openSUSE_Factory x86_64
for the leading-edge target is, without extra commands to see which repos exist, guesswork more often than not.
On 23.04.17 16:53 Jan Engelhardt wrote:
Are there no pressing issues really? How about the Factory vs Tumbleweed problem is solved first..
+1
And add to this the factory-tumbleweed-confusion of end users, this makes it even more pressing to have a consistent naming of repos.
<confusion mode> Is this factory as in old factory? Or is it factory as in "snaphot aka tumbleweed"? </confusion mode>
Johannes
On 04/23/2017 11:15 AM, Richard Brown wrote:
On 23 April 2017 at 10:55, Matwey V. Kornilov matwey.kornilov@gmail.com wrote:
22.04.2017 14:37, Richard Brown пишет:
Hi all,
On behalf of the openSUSE Board and Leap Release Management I am pleased to announce the next version of openSUSE Leap after 42.3 will be:
openSUSE Leap 15
What version will be after openSUSE Leap 41?
Leap and SLE major versions come out on average about once every 4 years.
So with this plan, starting at openSUSE Leap 15 in 2018, Leap 41 should be 104 years away
Ask this question again in 2122 and we'll figure out the answer then.
Your math is really fun. SLE just jumps from 12 to 15 but you still assume that it would be increased by 1 for the next 100 years. Your other funny assumption is that SLE would never do similar crazy huge forward and backward jumps like you prefer. In other words you also believe in monotonic version numbers, nevertheless you act different than the rest of the world.
cu, Rudi
I think part of the confusion (at least for me) is that there are two independent version numbering systems: one in /etc/os-release, and another in RPM macros.
The RPM macros have increased without a big gap, and will not go backwards. OBS and the package building is probably happy. Nothing unusual is happening there. Probably the same with zypper, as it uses the information in the RPMS. Of course, any RPM install-time scripts that might get run could potentially be confused if they rely on the OS version to get something correct.
/etc/-os-release has increased with a big gap (13.3 -> 42.1) and will perhaps now go backwards (42.2 -> 15.1). Everything outside of RPM/zypper is potentially messed up. This includes Makefiles, shell scripts, and probably most things outside RPM/zypper. It is this type of stuff that I am most concerned about.
OOC, is there any reliable way outside RPM to get access to the version that RPM would use? Something other than /etc/os-release?
On 25/04/2017 10:22, Roger Oberholtzer wrote:
I think part of the confusion (at least for me) is that there are two independent version numbering systems: one in /etc/os-release, and another in RPM macros.
The RPM macros have increased without a big gap, and will not go backwards. OBS and the package building is probably happy. Nothing unusual is happening there. Probably the same with zypper, as it uses the information in the RPMS. Of course, any RPM install-time scripts that might get run could potentially be confused if they rely on the OS version to get something correct.
/etc/-os-release has increased with a big gap (13.3 -> 42.1) and will perhaps now go backwards (42.2 -> 15.1). Everything outside of RPM/zypper is potentially messed up. This includes Makefiles, shell scripts, and probably most things outside RPM/zypper. It is this type of stuff that I am most concerned about.
OOC, is there any reliable way outside RPM to get access to the version that RPM would use? Something other than /etc/os-release?
Apart from macros under /etc/rpm and /usr/lib/rpm there's nothing AFAIK. Dave P
On Tue, Apr 25, 2017 at 4:30 AM, Dave Plater dplater.list@gmail.com wrote:
OOC, is there any reliable way outside RPM to get access to the version that RPM would use? Something other than /etc/os-release?
Apart from macros under /etc/rpm and /usr/lib/rpm there's nothing AFAIK.
As in
$ grep suse_version /usr/lib/rpm/suse_macros %suse_version 1315
But be very careful with it too. 1315 is for Leap 42.1. 1320 was openSUSE 13.2
spec file logic can be quite convoluted due to one-off decisions in setting the macros.
openSUSE - the pathological distro. Can't decide if it is coming or going!
As I read Richard's comments: === We screwed up the rpm macros for packagers when we released Leap. But it doesn't seem fair to keep that pain for only the packagers, so we are going to do a back jump for non-packagers as well. ===
You have suse_version, sle_version, and leap_version. To figure out what release you are in, you have to know which one to check:
openSUSE Factory %if 0%{?suse_version} > 1320 openSUSE Leap 42.3 %if 0%{?leap_version} == 420300 openSUSE Leap 42.2 %if 0%{?leap_version} == 420200 openSUSE Leap 42.1 %if 0%{?sle_version} == 120100 openSUSE Leap 42.x %if 0%{?suse_version} == 1315 openSUSE 13.2 %if 0%{?suse_version} == 1320 openSUSE 13.1 %if 0%{?suse_version} == 1310
fyi: the logic was pretty sane before Leap came out
Greg
On 25/04/2017 13:13, Greg Freemyer wrote:
As in
$ grep suse_version /usr/lib/rpm/suse_macros %suse_version 1315
On 42.2: grep sle_version /usr/lib/rpm/suse_macros %sle_version 120200
But be very careful with it too. 1315 is for Leap 42.1. 1320 was openSUSE 13.2
I no longer use %suse_version for Leap only the above %sle_version && is_opensuse
spec file logic can be quite convoluted due to one-off decisions in setting the macros.
openSUSE - the pathological distro. Can't decide if it is coming or going!
As I read Richard's comments:
We screwed up the rpm macros for packagers when we released Leap. But it doesn't seem fair to keep that pain for only the packagers, so we are going to do a back jump for non-packagers as well. ===
You have suse_version, sle_version, and leap_version. To figure out what release you are in, you have to know which one to check:
openSUSE Factory %if 0%{?suse_version} > 1320 openSUSE Leap 42.3 %if 0%{?leap_version} == 420300 openSUSE Leap 42.2 %if 0%{?leap_version} == 420200 openSUSE Leap 42.1 %if 0%{?sle_version} == 120100 openSUSE Leap 42.x %if 0%{?suse_version} == 1315 openSUSE 13.2 %if 0%{?suse_version} == 1320 openSUSE 13.1 %if 0%{?suse_version} == 1310
fyi: the logic was pretty sane before Leap came out
Greg
%leap_version only exists in the actual obs project configuration. I'm relieved I never used %leap_version and only used macros that exist locally as well. Some people use source rpms I think.
Dave P
Hello,
Am Dienstag, 25. April 2017, 10:22:58 CEST schrieb Roger Oberholtzer:
I think part of the confusion (at least for me) is that there are two independent version numbering systems: one in /etc/os-release, and another in RPM macros.
It was only independent in Leap 42.x - in all previous releases, suse_version matched /etc/os-release IIRC. Well, the dot was removed and a zero added, but for a human it looked similar.
BTW: That's also the reason why SLE12 and Leap 42.2 have that strange 1315 suse_version - SLE12 was branched off between openSUSE 13.1 and 13.2.
/etc/-os-release has increased with a big gap (13.3 -> 42.1) and will perhaps now go backwards (42.2 -> 15.1). Everything outside of
The first Leap 15 release will be 15.0 (as in "based on pure SLE 15, no service pack yet"), not 15.1 (as in SLE 15 SP1).
When Leap was "invented", it started with SLE 12 SP1, therefore Leap 42.1.
Oh, and 13.3 never existed - the release before Leap 42.1 was 13.2.
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.
RPM/zypper is potentially messed up. This includes Makefiles, shell scripts, and probably most things outside RPM/zypper. It is this type of stuff that I am most concerned about.
OOC, is there any reliable way outside RPM to get access to the version that RPM would use? Something other than /etc/os-release?
Not as a plain file AFAIK [1], but it's easy to query it:
# rpm --eval '%suse_version' 1330
This should also make it obvious that I'm writing this mail on Tumbleweed ;-)
Regards,
Christian Boltz
[1] In theory you could parse /usr/lib/rpm/suse_macros, but you'll have fun[tm] doing it. The rpm --eval way is much easier.
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.
(I will refer to Leap 42.x as "openSUSE 14.x" from now on, as this is what they obviously are).
On Tue, Apr 25, 2017 at 4:22 AM, Roger Oberholtzer roger.oberholtzer@gmail.com wrote:
/etc/-os-release has increased with a big gap (13.3 -> 42.1) and will perhaps now go backwards (42.2 -> 15.1).
After 42.2 will be 42.3.
The discussion is about the release after that, ~18 months from now.
42.2 => 42.3 42.3 => 15.0 (or just plain 15)
seems to be the way it will be.
Greg
On 04/25/2017 02:26 PM, Christian Boltz wrote:
Hello,
Am Dienstag, 25. April 2017, 10:22:58 CEST schrieb Roger Oberholtzer:
I think part of the confusion (at least for me) is that there are two independent version numbering systems: one in /etc/os-release, and another in RPM macros.
It was only independent in Leap 42.x - in all previous releases, suse_version matched /etc/os-release IIRC. Well, the dot was removed and a zero added, but for a human it looked similar.
That's not true.
To begin with, there is no previous version of Leap 42. For openSUSE *was* %suse_version matching /etc/os-release. For Tumbleweed this may be still true. For SLE it's %sle_version and for Leap it's %leap_version.
All the problems only occurred because of trying to build adventurous logic into the version numbers and trying to use one version number for different products.
BTW: That's also the reason why SLE12 and Leap 42.2 have that strange 1315 suse_version - SLE12 was branched off between openSUSE 13.1 and 13.2.
/etc/-os-release has increased with a big gap (13.3 -> 42.1) and will perhaps now go backwards (42.2 -> 15.1). Everything outside of
The first Leap 15 release will be 15.0 (as in "based on pure SLE 15, no service pack yet"), not 15.1 (as in SLE 15 SP1).
When Leap was "invented", it started with SLE 12 SP1, therefore Leap 42.1.
Oh, and 13.3 never existed - the release before Leap 42.1 was 13.2.
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.
RPM/zypper is potentially messed up. This includes Makefiles, shell scripts, and probably most things outside RPM/zypper. It is this type of stuff that I am most concerned about.
OOC, is there any reliable way outside RPM to get access to the version that RPM would use? Something other than /etc/os-release?
Not as a plain file AFAIK [1], but it's easy to query it:
# rpm --eval '%suse_version' 1330
This should also make it obvious that I'm writing this mail on Tumbleweed ;-)
Regards,
Christian Boltz
[1] In theory you could parse /usr/lib/rpm/suse_macros, but you'll have fun[tm] doing it. The rpm --eval way is much easier.
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.
Greg
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.
Instead the board is trying to teach us that there is no technical reason to increment version numbers... That's crazy.
cu, Rudi
On Tue, 25 Apr 2017, 14:53:28 +0200, Stefan Seyfried 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...
Read this thread now for quite a while... I completely agree with Stefan here, both from a developer point of view, but also from a SLE product manager point of view (I know quite a few of them...).
This would really help with all sorts of issues and problems that have been discussed here in great detail!
@Ludwig and Richard: don't you think this would be the best possible solution for all the potential problems noted?
This would still be tied to SLES in an obvious way, and not backwards from 42.x
Best of both worlds.
Yep, indeed!
Cheers.
l8er manfred
On Tue, 25 Apr 2017, 14:55:28 +0200, Greg Freemyer wrote:
On Tue, Apr 25, 2017 at 4:22 AM, Roger Oberholtzer roger.oberholtzer@gmail.com wrote:
/etc/-os-release has increased with a big gap (13.3 -> 42.1) and will perhaps now go backwards (42.2 -> 15.1).
After 42.2 will be 42.3.
The discussion is about the release after that, ~18 months from now.
42.2 => 42.3 42.3 => 15.0 (or just plain 15)
seems to be the way it will be.
To be honest, if this is the way "it seems to be", future trouble is already programmed. How will the version of Leap based on SLE 15 SP1 be called? Seife's proposal for
150 == derived from SLE 15 151 == derived from SLE 15 SP1 ...
would be *the* solution to get a final solution for these version number issues once and forever.
Greg
Cheers.
l8er manfred
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.
On Tuesday 2017-04-25 16:00, 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.
So %define leap_version %(eval %%suse_version + 2800))? Then you could write either %leap_version (base 42) or %suse_version (base 15) in your spec and be right at the same time.
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.
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
On 25.04.2017 15:14, Rüdiger Meier wrote:
I still don't get why do we need to be tied to SLES version numbers at all.
Well, there is no "need", but I would deem it useful. We might disagree here.
What is the technical reason behind this? It is pure unimportant cosmetics.
It makes things certainly less confusing if the two "products" openSUSE and SLES which have certain connections (a common code base) have similar version numbers.
Instead the board is trying to teach us that there is no technical reason to increment version numbers... That's crazy.
I agree here. That would be solved by using 150... for openSUSE, which is still related to SLES ("10 times SLES", this would actually be a good marketing pitch as there is so much more content in openSUSE then is in SLES). The "incrementing version numbers" problem would be solved as well.
But I do not believe that the board is going to accept *any* solution now.
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".
cu, Rudi
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2017-04-25 14:53, Stefan Seyfried wrote:
(I will refer to Leap 42.x as "openSUSE 14.x" from now on, as this is what they obviously are).
Can't be backported... :-(
- -- Cheers / Saludos,
Carlos E. R.
(from 42.2 x86_64 "Malachite" (Minas Tirith))
-
Carlos E. R. -
Christian Boltz -
Dave Plater -
Greg Freemyer -
Jan Engelhardt -
Johannes Kastl -
Manfred Hollstein -
Richard Brown -
Roger Oberholtzer -
Rüdiger Meier -
Simon Lees -
Stefan Seyfried