On 04/23/2017 07:09 PM, Richard Brown wrote:

On 23 April 2017 at 11:36, Stefan Seyfried 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). -- 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 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"? Johannes

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

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

Seit wann gibts denn eine Linux Version von "The Bat"? Ich glaube kaum, das sich der Pinguin mit ner Fledermaus einlässt. [> Oliver Arp und Michael Raab in suse-linux]

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

On 04/25/2017 03:05 PM, Greg Freemyer wrote:

...

On Tue, Apr 25, 2017 at 8:53 AM, 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...

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

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

On Tue, Apr 25, 2017 at 4:22 AM, Roger Oberholtzer 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