View Issue Details

IDProjectCategoryView StatusLast Update
0008359CentOS-7centos-releasepublic2018-08-10 17:20
Reporterdaxkelson 
PriorityurgentSeveritymajorReproducibilityalways
Status assignedResolutionopen 
PlatformOSOS Version7.1
Product Version 
Target VersionFixed in Version 
Summary0008359: v7.1 /etc/os-release doesn't have minor version unlike RHEL and Oracle Linux
DescriptionOur software supports RHEL and its clones and other Linux distros, I need to be able to parse the /etc/os-release and get the minor rev.

I can do this with RHEL, Oracle Linux, SUSE and Ubuntu. I can't do this with CentOS:

grep VERSION_ID rhel7.1-etc-os-release
VERSION_ID="7.1"

grep VERSION_ID oracle-linux7.1-etc-os-release
VERSION_ID="7.1"

grep VERSION_ID centos7.0-etc-os-release
VERSION_ID="7"

grep VERSION_ID centos7.1-etc-os-release
VERSION_ID="7"

It's really important to be able to get the minor release out of /etc/os-release. Out software stopped parsing the various ad-hoc /etc/<distro>-release files and switched to using /etc/os-release, but CentOS is one casuing problem.
Additional Informationcentos-release-7-1.1503.el7.centos.2.8.x86_64
TagsNo tags attached.
abrt_hash
URL

Relationships

has duplicate 0009448 assignedkbsingh@karan.org VERSION_ID in /etc/os-release does not contain the full version number 
has duplicate 0008555 assignedkbsingh@karan.org VERSION_ID Field under "/etc/os-release" not filled out with subversion 

Activities

daxkelson

daxkelson

2015-12-11 05:28

reporter   ~0025041

Please, fix this for the 7.2 release.

/etc/os-release

VERSION_ID="7.2" just like RHEL7.2 and Oracle Linux 7.2
toracat

toracat

2015-12-17 08:13

manager   ~0025105

Any comment about this, @kbsingh ?
avij

avij

2016-01-21 00:14

manager   ~0025447

daxkelson: What is your use case? You say it's really important to be able to get the minor release, but why? How would you be using the minor release number in your software? Note that having some specific number in /etc/os-release does not guarantee anything about other installed packages. For example, some people might run an older kernel even if centos-release is up to date.
toracat

toracat

2016-01-21 00:46

manager   ~0025448

Last edited: 2016-01-21 00:47

View 2 revisions

I'd like to ask a question from the opposite (?) angle. If VERSION_ID is changed to 7.1, what inconveniences would it cause in the CentOS Project? That is, what would it break?

[EDIT] I meant 7.2 (or whatever is current).

ptoscano

ptoscano

2016-02-16 12:56

reporter   ~0025740

@avij: having the full version available allows to properly identify what the current installation is.

My case (#9448) is about libguestfs identifying disk images; if libguestfs were to rely solely on what /etc/os-release provides, then 3 disk images with CentOS 7.0, 7.1, and 7.2 would *all* be identified as "centos" version 7.0, which is not really the case.

After all, /etc/centos-release contains already the full version number of the CentOS installation, so it does not make sense to "hide" the full version from os-release while the classic centos-release provides it. Please make it available in both.
kbsingh@karan.org

kbsingh@karan.org

2016-02-16 13:00

administrator   ~0025741

why would we want to identify 7.0 / 7.1 and 7.2 on their own ? they are only CentOS-7 with different points in time updates, since there is no 7.0 or 7.1 etc
ptoscano

ptoscano

2016-02-16 13:06

reporter   ~0025742

> they are only CentOS-7 with different points in time updates, since there is no 7.0 or 7.1 etc

Exactly! And the current os-release gives no information about that, while 7.2.1511 vs 7.1.etc vs 7.0.etc gives more details about that, even because in libguestfs we show also a string with the product description:

$ virt-inspector -a centos-7.qcow2
[...]
    <product_name>CentOS Linux release 7.2.1511 (Core) </product_name>
    <major_version>7</major_version>
    <minor_version>2</minor_version>
[...]

(libguestfs still uses centos-release on CentOS, because of this bug.)
damona

damona

2016-02-24 13:28

reporter   ~0025835

Found this https://access.redhat.com/solutions/401413
 and https://en.wikipedia.org/wiki/CentOS#Versioning

I notice that http://mirror.centos.org/centos/ does not have minor numbers in the path for CentOS 7 and almost CentOS 6. Oracle have latest and http://public-yum.oracle.com/repo/OracleLinux/OL7/2/base/x86_64/index.html

General vendors produce updates to minor versions e.g. 7.1 and 7.2 at the same time but add no new packages. i.e. new software.

I assume/hope RHEL minor release are fully tested point in time.

Announcement e.g. "Several issues have been found in CENTOS 7.1 combined they an result in a crash, please upgrade to at least 7.5"

If I want to compare check which systems are running 7.1 across a fleet of Oracle Linux, RHEL, and CentOS which is the best way to do it?

So if rpm abcd-1.0 was added to CentOS after release 7.3, instead you would say upgrade 7.3 and install the software if needed. Or you might not even attempt to install the software, you might add a private repo instead and install it from this.


If I take something compiled against or create against 7.8 can I run it on 7.1?

Or a Docker image created on 7.8 and run it on 7.1?

So I can see why an app is fine on one and not another.

See also http://0pointer.de/blog/projects/os-release
and http://0pointer.de/blog/projects/os-release.html
and http://www.freedesktop.org/software/systemd/man/os-release.html

What do you want the community to do? How do you want us to treat differences between releases?
i.e. Shell Scripts, SaltStack, Ansible, Saltstack, Chef, Puppet & CFengine

Alternatively if you update VERSION_ID to 7.x then people can decide if they want to use the 7.x or strip off the .x

Just asking the questions so we can understand CentOS maintainers thinking?
jlsherrill

jlsherrill

2016-04-20 17:50

reporter   ~0026339

Adding a +1 to this bug report. The foreman & Katello project uses it to report what version of Centos was installed from a kickstart tree.

RHEL seems to value this minor version quite a bit, so i don't see much reason for centos to ignore it. If its really not important why even update /etc/redhat-release ?
furlongm

furlongm

2016-12-07 00:39

reporter   ~0028089

Also adding a +1 to this bug report, as this is causing issues for us.
sysmgr

sysmgr

2018-01-31 22:07

reporter   ~0031140

+1 for ease of implementation:

--- centos-release.spec 2018-01-31 13:38:22.262783849 -0800
+++ centos-release.spec.sysmgr 2018-01-31 13:51:59.664359267 -0800
@@ -54,12 +54,15 @@
 ID="centos"
 ID_LIKE="rhel fedora"
 VERSION_ID="%{full_release_version}"
+BUILD_ID="%{full_release_version}.%{centos_rel}"
+VARIANT="centos-%{full_release_version}.%{centos_rel}"
 PRETTY_NAME="%{product_family} %{full_release_version} (%{release_name})"
 ANSI_COLOR="0;31"
 CPE_NAME="cpe:/o:centos:centos:7"
 HOME_URL="https://www.centos.org/"
 BUG_REPORT_URL="https://bugs.centos.org/"

+CENTOS_FULL_PRETTY_NAME="%{product_family} %{full_release_Version}.%{centos_rel} (%{release_name})"
 CENTOS_MANTISBT_PROJECT="CentOS-7"
 CENTOS_MANTISBT_PROJECT_VERSION="7"
 REDHAT_SUPPORT_PRODUCT="centos"
 
-------------------------------------------
Reasoning:

- "CentOS Linux aims to be functionally compatible with RHEL. We mainly change packages to remove upstream vendor branding and artwork." -

While technically that does not state CentOS will be identical to upstream, the spirit behind it is "we change as little as possible". So, in that spirit, here are the objective reasons for including minor version information in os-release:

 - Upstream includes the minor version information in os-release.
 - CentOS would be more in line with upstream, which is a stated goal.
 - User's are experiencing issues due to this CentOS difference from upstream.


... and here are some subjective reasons:

CentOS has developed an extremely loyal community. Past practices by the CentOS core group have resulted in a stable, reliable, predictable platform upon which we can confidently develop our applications and infrastructures. Because of this we support CentOS vehemently via our wallets, corporate boardroom meetings, forums, etc. We've stuck by you through shaky times and organizational changes. You've earned and deserve our support. We've earned and deserve this appropriate fix.

The purpose of os-release, and the subsequent decision by freedesktop.org (systemd) to drop support for any OS that doesn't implement it, is to meet a substantial need for a standardized, extensible facility capable of determining platform specifics. Not including specifics in os-release is contrary to that purpose and renders it fairly useless.
https://www.freedesktop.org/software/systemd/man/os-release.html
http://0pointer.de/blog/projects/os-release.html
amahdal

amahdal

2018-08-10 17:20

reporter   ~0032460

+1

This makes test code that operates with these values unnecessarily complicated: /etc/os-release has been designed to be easy to read and now we have to fall back to parsing strange version numbers or whatnot.

Issue History

Date Modified Username Field Change
2015-04-01 15:48 daxkelson New Issue
2015-12-11 05:28 daxkelson Note Added: 0025041
2015-12-11 07:41 toracat Relationship added has duplicate 0009448
2015-12-11 07:42 toracat Relationship added has duplicate 0008555
2015-12-11 07:56 toracat Status new => assigned
2015-12-17 08:13 toracat Note Added: 0025105
2016-01-21 00:14 avij Note Added: 0025447
2016-01-21 00:46 toracat Note Added: 0025448
2016-01-21 00:47 toracat Note Edited: 0025448 View Revisions
2016-02-16 12:56 ptoscano Note Added: 0025740
2016-02-16 13:00 kbsingh@karan.org Note Added: 0025741
2016-02-16 13:06 ptoscano Note Added: 0025742
2016-02-24 13:28 damona Note Added: 0025835
2016-04-20 17:50 jlsherrill Note Added: 0026339
2016-12-07 00:39 furlongm Note Added: 0028089
2018-01-31 22:07 sysmgr Note Added: 0031140
2018-08-10 17:20 amahdal Note Added: 0032460