I’m not exactly where such a request should go, but I’m finding the Update announcements slightly less useful that I believe that they could easily be. If these announcements could be labeled beyond the package name, I would find them much more useful. The two labels I feel are most important are the type, (bugfix, enhancement, etc.), and the severity, (critical, important, etc.) Ideally, both labels would be in the subject line and the body. This could also potentially decrease the resource consumption of Rocky resources by users looking up the changes. Sure all updates are important, but not necessarily affect security at a drop everything level. With today’s notification, that determination requires a lot more work, thus increasing the potential for ignoring the updates.
I do agree that having more information in the announcements would be more useful. But note that the announcements are manual at this time. Since they are manual, it’s a lot of work to go through and find every single severity level and every type of fix, especially when there’s more than just a handful of updates. There are also cases where updates are released but it is a mix of severities rather than just a single “yes all of these are important” or “all of these are critical”, which would be inefficient for a single subject line.
It’s not really simple and there really isn’t an automated process to this yet. The new build system we are looking to address this deficiency and remove human hands from majority of the process. This would mean instead of single email per set of updates, you may see one email per advisory instead, same as you would from Red Hat.
As an aside, dnf updateinfo will give you some information too.
[root@cm01 ~]# dnf updateinfo --summary
Last metadata expiration check: 1:57:47 ago on Fri 25 Feb 2022 10:29:02 PM MST.
Updates Information Summary: available
1 Security notice(s)
1 Important Security notice(s)
2 Enhancement notice(s)
Security: kernel-core-4.18.0-348.12.2.el8_5.x86_64 is an installed security update
Security: kernel-core-4.18.0-348.7.1.el8_5.x86_64 is the currently running version
[root@cm01 ~]# dnf updateinfo --list
Last metadata expiration check: 1:57:52 ago on Fri 25 Feb 2022 10:29:02 PM MST.
FEDORA-EPEL-2021-2d0f959e00 enhancement distribution-gpg-keys-1.64-1.el8.noarch
FEDORA-EPEL-2022-bc95045a9e enhancement epel-release-8-14.el8.noarch
RLSA-2022:176 Important/Sec. kernel-4.18.0-348.12.2.el8_5.x86_64
RLSA-2022:176 Important/Sec. kernel-core-4.18.0-348.12.2.el8_5.x86_64
RLSA-2022:176 Important/Sec. kernel-modules-4.18.0-348.12.2.el8_5.x86_64
FEDORA-EPEL-2021-2d0f959e00 enhancement mock-2.16-1.el8.noarch
FEDORA-EPEL-2021-2d0f959e00 enhancement mock-core-configs-37.1-1.el8.noarch
FEDORA-EPEL-2021-2d0f959e00 enhancement mock-filesystem-2.16-1.el8.noarch
The numbers for RL*A will match with upstream Red Hat advisories.
Thanks for taking the time to explain that. Having an automated system will definitely help, and I’ve got no problem getting an update for each individual package. In fact, for a SIEM system, that could be even more useful. May the awk sed correctly!