Use os-release instead of lsb_release

[schlomo]

I think that os-release is a good thing. All systemd based distros will ship that file and the content is well defined. We can pull all or at least most of our info from there as well.

I would therefore propose a completely different approach:

• Write code to parse os-release properly, following all the hints from the man page.
• On distros that ship os-release remove lsb* from the package dependencies.
• Use os-release if lsb_release is not available.

The result will be a smooth migration with minimal impact. And it is upgrade safe as we don't run any code on package installation. And it also works when you run ReaR from source code :-)

See 613ba6f for full discussion

[gdha]

Milestone (1.18) removed. No idea when this one will be fixed.

[gdha]

Issue #778 is a related issue.

[gdha]

referenced to the wrong issue - should have been #778. This issue has not been resolved yet!

[schlomo]

Just had a look again, with ID and ID_LIKE and VERSION_ID it contains IMHO all that we need to know.

@jsmeix would this be a way for more recent SUSE systems to avoid creating this os.conf during the RPM build process? The big big downside of build-time configuration is that a simple make install does not yield the same result as installing the package (hit me today on SLES10).

[jsmeix]

That build-time created os.conf file should definitely be dropped
for newer ReaR versions at least for SUSE because
since #1241
the SetOSVendorAndVersion function results "the right stuff"
at least for SUSE (regardless whether or not my current
implementation is really the best way to do it).

@schlomo
I fully agree that basically all build-time settings
have the problem that they may be wrong during run-time.

FYI:
I was hit by a missing os.conf when I used a git clone via

# git clone https://github.com/rear/rear.git

# cd rear

[gdha]

@schlomo on SLES10 I only find /etc/lsb-release and/or /etc/SuSE-release files, so that we still need to differentiate I guess

[gdha]

post-pone to release 2.3

[gdha]

@jsmeix Could you paste from a few SLES versions the output of grep "ID" /etc/os-release please?

[jsmeix]

SLE10:

# cat /etc/issue | grep -v '^$'
Welcome to SUSE Linux Enterprise Server 10 SP4 (x86_64) ...

# grep "ID" /etc/os-release
grep: /etc/os-release: No such file or directory

SLE11

# cat /etc/issue | grep -v '^$'
Welcome to SUSE Linux Enterprise Desktop 11 SP3 (i586) ...

# grep "ID" /etc/os-release
grep: /etc/os-release: No such file or directory

SLE12:

# cat /etc/issue | grep -v '^$'
Welcome to SUSE Linux Enterprise Server 12 SP2 (x86_64) ...

# grep "ID" /etc/os-release
VERSION_ID="12.2"
ID="sles"

openSUSE Leap (is based on SLE12):

# cat /etc/issue | grep -v '^$'
Welcome to openSUSE Leap 42.1 ...

# grep "ID" /etc/os-release
VERSION_ID="42.1"
ID=opensuse
ID_LIKE="suse"

openSUSE Tumbleweed (continuously changing rolling release):

# cat /etc/issue | grep -v '^$'
Welcome to openSUSE Tumbleweed 20170620 ...

# grep "ID" /etc/os-release
ID=opensuse
ID_LIKE="suse"
VERSION_ID="20170620"

[gdha]

@schlomo @jsmeix @gozora If we would remove os.conf spec generation from the spec file would it be an option to generate one on the prep work-flow? The file would be re-generated each time then, but that would fix capturing OS upgrades (VERSION_ID that would change)?

[gdha]

Issue #1639 will pick up where we left this issue. This one can be closed.