#731 Issue `closed`: Use os-release instead of lsb_release¶

Labels: enhancement, fixed / solved / done, minor bug

schlomo opened issue at 2015-12-04 09:50:¶

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 613ba6f379e0ad93e47f707f1ae351d781008732 for full discussion

gdha commented at 2016-01-21 09:06:¶

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

gdha commented at 2016-02-22 10:11:¶

Issue #778 is a related issue.

gdha commented at 2016-02-22 10:55:¶

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

schlomo commented at 2017-06-20 09:54:¶

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 commented at 2017-06-20 12:49:¶

That build-time created os.conf file should definitely be dropped
for newer ReaR versions at least for SUSE because
since https://github.com/rear/rear/pull/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 commented at 2017-07-11 10:24:¶

@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 commented at 2017-07-19 15:09:¶

post-pone to release 2.3

gdha commented at 2017-11-28 15:48:¶

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

jsmeix commented at 2017-11-29 09:08:¶

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 commented at 2017-11-29 17:10:¶

@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 commented at 2017-12-11 08:13:¶

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

[Export of Github issue for rear/rear.]

#731 Issue closed: Use os-release instead of lsb_release¶