Mailinglist Archive: opensuse-factory (1009 mails)

< Previous Next >
[opensuse-factory] openSUSE Leap's Next rpm macro values
  • From: Greg Freemyer <greg.freemyer@xxxxxxxxx>
  • Date: Tue, 25 Apr 2017 18:30:31 -0400
  • Message-id: <CAGpXXZJETPKaG1cXVask4z0tY=LRRJqFcC2cjfSGCSULSj3aEQ@mail.gmail.com>
On Tue, Apr 25, 2017 at 5:54 PM, Simon Lees <sflees@xxxxxxx> 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@xxxxxxxxxxxxxx> 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
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups