[opensuse-factory] Re: [opensuse-project] Re: openSUSE Leap's Next Major Version Number
On 23 April 2017 at 10:55, Matwey V. Kornilov <matwey.kornilov@gmail.com> wrote:
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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 23.04.2017 um 11:15 schrieb Richard Brown:
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. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23 April 2017 at 11:36, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
I wouldn't be opposed to the removal of 'openSUSE_' from the build target names for Leap and Tumbleweed. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/23/2017 07:09 PM, Richard Brown wrote:
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). -- 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 Sunday 2017-04-23 11:39, Richard Brown wrote:
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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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:
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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Apr 25, 2017 at 4:30 AM, Dave Plater <dplater.list@gmail.com> wrote:
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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25/04/2017 13:13, Greg Freemyer wrote:
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
%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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Dienstag, 25. April 2017, 10:22:58 CEST schrieb Roger Oberholtzer:
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.
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. --
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25.04.2017 14:26, Christian Boltz wrote:
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). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Apr 25, 2017 at 8:53 AM, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
At a minimum that should be done in /etc/issue. And maybe %leap_version 1500000, 1510000, 1520000, 1600000, ... in rpm macros. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/25/2017 03:05 PM, Greg Freemyer wrote:
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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/25/2017 10:44 PM, Rüdiger Meier wrote:
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. -- 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 Tuesday 2017-04-25 16:00, Simon Lees wrote:
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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/25/2017 11:30 PM, Simon Lees wrote:
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 -- 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/25/2017 04:11 PM, Simon Lees wrote:
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.
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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/25/2017 11:57 PM, Rüdiger Meier wrote:
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. -- 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 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. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 25 Apr 2017, 14:53:28 +0200, Stefan Seyfried wrote:
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
-----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)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlj/1boACgkQja8UbcUWM1y/dAD8CU8KPT2p9lZzanbOTONuHUHK Y0p3aKrTtddMNfOTIFIA/Ro9N54YRa6pMk6cVSN/Vf5qSnAcxOprwTsGEwEpa3/C =/WiM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/25/2017 02:26 PM, Christian Boltz wrote:
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.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 25 Apr 2017, 14:55:28 +0200, Greg Freemyer wrote:
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
Am 23.04.2017 um 11:15 schrieb Richard Brown:
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. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23 April 2017 at 11:36, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
I wouldn't be opposed to the removal of 'openSUSE_' from the build target names for Leap and Tumbleweed. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/23/2017 07:09 PM, Richard Brown wrote:
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). -- 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 Sunday 2017-04-23 11:39, Richard Brown wrote:
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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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:
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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Apr 25, 2017 at 4:30 AM, Dave Plater <dplater.list@gmail.com> wrote:
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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25/04/2017 13:13, Greg Freemyer wrote:
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
%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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Dienstag, 25. April 2017, 10:22:58 CEST schrieb Roger Oberholtzer:
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.
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. --
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25.04.2017 14:26, Christian Boltz wrote:
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). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Apr 25, 2017 at 8:53 AM, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
At a minimum that should be done in /etc/issue. And maybe %leap_version 1500000, 1510000, 1520000, 1600000, ... in rpm macros. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/25/2017 03:05 PM, Greg Freemyer wrote:
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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/25/2017 10:44 PM, Rüdiger Meier wrote:
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. -- 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 Tuesday 2017-04-25 16:00, Simon Lees wrote:
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. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/25/2017 11:30 PM, Simon Lees wrote:
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 -- 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/25/2017 04:11 PM, Simon Lees wrote:
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.
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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/25/2017 11:57 PM, Rüdiger Meier wrote:
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. -- 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 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. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 25 Apr 2017, 14:53:28 +0200, Stefan Seyfried wrote:
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
-----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)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlj/1boACgkQja8UbcUWM1y/dAD8CU8KPT2p9lZzanbOTONuHUHK Y0p3aKrTtddMNfOTIFIA/Ro9N54YRa6pMk6cVSN/Vf5qSnAcxOprwTsGEwEpa3/C =/WiM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/25/2017 02:26 PM, Christian Boltz wrote:
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.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 25 Apr 2017, 14:55:28 +0200, Greg Freemyer wrote:
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
participants (12)
-
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