Full qualified release info

Rocky Linux General
1

Hi rockies,

how I can determine correct and full qualified version of rocky linux like " 8.5 - 2021-12-09".

See mor here: Change Log - Documentation

Regards
Matthias

2

The “8.5” is version. Red Hat did release RHEL 8.5, which did replace/update several packages compared to RHEL 8.4.
Rocky did build its 8.5 from published sources of RHEL 8.5.

Between these “point updates” RHEL (and hence Rocky) releases occasional, critical (security) updates for some packages, as necessary. The “version” remains the same.

You either have 8.5, or you have 8.5 where you have installed available interim updates.
Note that Rocky does flag these interim updates with metadata, you can selectively install only packages that certainly affect security, or simply install all updates.

The " 2021-12-09" change did release updates for one component only: the thunderbird email client.
What if your system does not have thunderbird installed? Would it be different “fully qualified” from system that does have thunderbird, or from system that has thunderbird, but hasn’t installed the latest update? They are all “8.5” systems.

There are some /etc/*-release files. Look at them. Then run dnf check-update. If it lists nothing new, then you are at the “latest version”.

déjà-vu

3

Hello @jlehtone ,

I have a completely different view of it.

Version 8.5 from 2021-12-09 and version 8.5 from 2021-12-10 are different! And this is also described in the release notes: Change Log - Documentation

In the /etc/*-release information there is no reference to the current running version. I don’t know any other way to find out. Does anyone know one?

From my point of view this is indispensable for enterprise use (IT security, release management etc.).

Regards
Matthias

4

I’m not completely sure I understand what the question is or what you mean by “fully qualified version”, these would tell you what the current running version is:

  • rpm -q rocky-release
  • cat /etc/os-release – Found on VERSION_ID and full name is PRETTY_NAME
  • cat /etc/rocky-release
[root@cm01 ssh]# cat /etc/os-release
NAME="Rocky Linux"
VERSION="8.5 (Green Obsidian)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.5"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Rocky Linux 8.5 (Green Obsidian)"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:rocky:rocky:8:GA"
HOME_URL="https://rockylinux.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
ROCKY_SUPPORT_PRODUCT="Rocky Linux"
ROCKY_SUPPORT_PRODUCT_VERSION="8"

[root@cm01 ssh]# cat /etc/rocky-release
Rocky Linux release 8.5 (Green Obsidian)

[root@cm01 ssh]# rpm -q rocky-release
rocky-release-8.5-2.el8.noarch

Updates that happen within the 6 month cycle of a release will remain as “8.5” or whatever the minor version is. Next may, when 8.6 is released, all the 8.5 references will become 8.6 and packages updated during that cycle get el8_6 on their dist tag in the NEVRA.

5

We are approaching the thing in a philosophical way, building mental maps, without a practical approach? Here I go:

Even the notion of point releases is an illusion [1]. There is only Rocky 8. Think about it: there is no supported way to stay on 8.4 (with RHEL that is possible but not with it’s clones), so what is a point release good for anyway, apart from a good possibility to produce new ISO Images, to save bandwidth?

[1] bear with me, please :wink:

6

I’m actually more to the other extreme than what I did say before. I see only two versions of EL8:

  • “Up to date”. All installed packages updated to their latest available versions
  • Not up to date EL8

Both change over time. Hence there is no “8.4”, “8.5”, or “8.6” for me, just “8”. That is the way it has been with CentOS Linux and presumably will remain with Rocky. Admittedly, this view depends on monotonous improvement; no regressions. “Latest available” is assumed to be better than anything before. Granted, there have been some regressions that have forced downgrade or postpone of update of individual components.

The RHEL offers paid maintenance for (some) earlier point update branches, but no finer granularity, AFAIK.

Yes, this is a question about version control. You expect “commit identifiers” that cover every package in the distro. That you can refer to specific set of versions with an identifier. However, if you would get independent updates to two components the same day and one of them had regression, how would you refer to “version 2021-12-10, except for ‘openscap’ that was kept as in version 2021-12-09”?

However, we don’t have access to such metadata; the individual components get updates “independently”. For example, the packages released 2021-12-09 made a difference only to those setups that had thunderbird installed. While the “2021-12-03–2021-12-09” was different from “2021-12-09–2021-12-10” for some users, it was not for all.

As for “enterprise use”, you should ask from Red Hat whether they have “fully qualified identifiers” for RHEL.
If they don’t, then that must be “good enough” for their paying customers.
For the price I pay for Rocky, the “up to date” is good enough for me. (Granted, I am not an enterprise.)