Hai All,
Last night I’ve upgraded my Rocky Linux to 8.5 successfully even the conflict library error exist during update, I use this command to upgrade Rocky Linux to 8.5
sudo dnf list kernel
sudo dnf update --allowerasing --nobest
Done
All application like vagrant, ssh, webserver, etc working normally and no error after upgrade to Rocky Linux 8.5.
Thanks you very much to Rocky Linux Developers for great update.
Personally, I’d rather solve conflicts manually than use --allowerasing --nobest.
Note that it is possible to post text instead of bitmap screenshots:
$ sudo dnf --enablerepo=epel install neofetch
Last metadata expiration check: 0:00:53 ago on Wed 17 Nov 2021 09:44:26 AM EET.
Dependencies resolved.
===================================================================================================================
Package Architecture Version Repository Size
===================================================================================================================
Installing:
neofetch noarch 7.1.0-6.el8 epel 94 k
Installing dependencies:
ImageMagick-libs x86_64 6.9.10.86-1.el8 epel 2.3 M
...
How to solve that conflict library manually,? I run your command sugestion above but actually I already added epel repo, and still doesn’t solve the conflict library
$ sudo dnf --enablerepo=epel install neofetch
Last metadata expiration check: 19:06:00 ago on Sel 16 Nov 2021 08:00:35 WIB.
Package neofetch-7.1.0-6.el8.noarch is already installed.
Dependensi terselesaikan.
Tidak ada yang dilakukan.
Selesai!
$ sudo dnf repolist
id repo nama repo
appstream Rocky Linux 8 - AppStream
baseos Rocky Linux 8 - BaseOS
epel Extra Packages for Enterprise Linux 8 - x86_64
epel-modular Extra Packages for Enterprise Linux Modular 8 - x86_64
extras Rocky Linux 8 - Extras
hashicorp Hashicorp Stable - x86_64
microsoft-edge microsoft-edge
powertools Rocky Linux 8 - PowerTools
rpmfusion-free-updates RPM Fusion for EL 8 - Free - Updates
virtualbox Oracle Linux / RHEL / CentOS-8 / x86_64 - VirtualBox
$ sudo dnf update
Last metadata expiration check: 19:06:20 ago on Sel 16 Nov 2021 08:00:35 WIB.
Galat:
Problem 1: package libstdc++-devel-8.5.0-3.el8.x86_64 requires libstdc++(x86-64) = 8.5.0-3.el8, but none of the providers can be installed
- cannot install both libstdc++-8.5.0-4.el8_5.x86_64 and libstdc++-8.5.0-3.el8.x86_64
- cannot install the best update candidate for package libstdc++-devel-8.5.0-3.el8.x86_64
- cannot install the best update candidate for package libstdc++-8.5.0-3.el8.x86_64
Problem 2: libgomp-8.5.0-3.el8.i686 has inferior architecture
- package gcc-8.5.0-3.el8.x86_64 requires libgomp = 8.5.0-3.el8, but none of the providers can be installed
- cannot install both libgomp-8.5.0-4.el8_5.x86_64 and libgomp-8.5.0-3.el8.x86_64
- cannot install the best update candidate for package libgomp-8.5.0-3.el8.x86_64
- cannot install the best update candidate for package gcc-8.5.0-3.el8.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
My example was about posting “code”. (I don’t have epel enabled, and I did not install that “neofetch” package – no need for such tool nor all the packages it would have pulled in.)
You show issue with these:
libstdc++-devel-8.5.0-3.el8.x86_64
libstdc++-8.5.0-4.el8_5.x86_64
Where do they come from? dnf list libstdc++-devel libstdc++
The libstdc++ is in baseos, while libstdc+±devel is in appstream.
My nearest Rocky mirror has version 8.5.0-4.el8_5 of both (dated 2021-11-10).
I often dnf --enablerepo=* clean all to ensure that dnf does not use invalid cache.
I’ve just solved this dependency library conflict with this command:
sudo dnf clean all
then I tried to sudo dnf update and voila the conflict library dependency doesn’t exist anymore. like in My SS below:
Done. Btw Thank you for your explanation and sugestion, I think Rocky Linux developer have done to solve this conflict library dependency.
I have these on a clean install. The problem is with the new packages, instead of naming them el8 to replace the existing ones, they called them el8_5 which I think is totally wrong. The same happened with python3-pip when 8.4 released it was 8_4 and something depended on el8, then after cleaning the repos or using the rocky one instead of mirrorlist I was able to get around it.
EDIT:
after doing a dnf clean all today, it’s now starting to work properly and the packages are upgrading.
The el8 => el8_5 rename is done by Red Hat for RHEL packages.
Example for libstdc++: Red Hat Customer Portal - Access to 24x7 support and knowledge
A point update has “el8” in package names. (Actually, as part of “Release” string. Not part of “Version”.)
For some updates between point releases they rename that release to x.el8_n (where n is current point release.
The real issue here seems to be that dnf does not reliably spot that repos have new content.
(That could be “by design”, to decrease network traffic.)
Seems strange to do that though @jlehtone for example on Rocky:
[root@rocky ~]# rpm -qa | grep 8_4 | sort
ca-certificates-2021.2.50-80.0.el8_4.noarch
kernel-4.18.0-305.25.1.el8_4.x86_64
kernel-core-4.18.0-305.25.1.el8_4.x86_64
kernel-devel-4.18.0-305.25.1.el8_4.x86_64
kernel-modules-4.18.0-305.25.1.el8_4.x86_64
libdb-5.3.28-42.el8_4.x86_64
libdb-utils-5.3.28-42.el8_4.x86_64
lz4-libs-1.8.3-3.el8_4.x86_64
nspr-4.32.0-1.el8_4.x86_64
nss-3.67.0-6.el8_4.x86_64
nss-softokn-3.67.0-6.el8_4.x86_64
nss-softokn-freebl-3.67.0-6.el8_4.x86_64
nss-sysinit-3.67.0-6.el8_4.x86_64
nss-tools-3.67.0-6.el8_4.x86_64
nss-util-3.67.0-6.el8_4.x86_64
sudo-1.8.29-7.el8_4.1.x86_64
unzip-6.0-45.el8_4.x86_64
so there are el8_4 packages installed, but:
[root@rocky ~]# cat /etc/redhat-release
Rocky Linux release 8.5 (Green Obsidian)
supposedly I am on Rocky 8.5. So all those el8_4 packages should be el8_5. Which in reality doesn’t make sense to do it that way, but rather just el8 and a package version number change. Obviously someone decided it was a good reason to do that, but now I have a mishmash of a system which has 8.4 and 8.5 packages installed, when it should be completely 8.5. Although obviously, if it was just el8, by package names alone I wouldn’t be able to tell if my system was a mix of 8.4 and 8.5 packages, but only via the content of /etc/redhat-release or /etc/rocky-release.
I think there might have been some mirror issues yesterday that didn’t help, as they worked fine this morning though when updating again with a refresh of dnf.
I can’t find where I saw a discussion. It was not this: Understanding Package Naming convention - Red Hat Customer Portal
When was the last time that those packages were updated? Bet that not on 8.5 update.
The kernels of 8.4 obviously are el8_4 content.
Here a history from one machine:
# dnf history info yum | grep yum
Upgrade yum-4.7.0-4.el8.noarch @baseos
Reinstall yum-4.4.2-11.el8.noarch @baseos
Upgrade yum-4.4.2-11.el8.noarch @BaseOS
Upgrade yum-4.2.23-4.el8.noarch @BaseOS
Upgrade yum-4.2.17-7.el8_2.noarch @BaseOS
Upgrade yum-4.2.17-6.el8.noarch @BaseOS
Upgrade yum-4.2.7-7.el8_1.noarch @BaseOS
Install yum-4.0.9.2-5.el8.noarch @anaconda
Note how most were “el8”, but two had “el8_1” and “el8_2”?
Yep, understand what you are getting at, although that would be even more reason to keep it as el8 rather than el8_4. It would be far better, for example to do this, so instead of:
yum-4.2.17-7.el8_2.noarch
have it as:
yum-4.2.17-8.el8.noarch
by just changing the 17-7 to 17-8. Since later, when it got to 8.3 or higher, it became yum-4.2.23 anyway so there was plenty of room in between just to do really minor point releases for updates applied during 8.2 for example.
I’m OK with it being el8_4 or el8_5 in a sense, but it would be far less confusing as by looking at my package list, it looks like I have a partially upgraded 8.4 and 8.5 system running.
Rocky’s 8.5 repo shows unzip-6.0-45.el8.x86_64. Same version.
Red Hat does support some RHEL point releases longer, with EUS. They essentially “branch” the point release at some point, while the “main branch” already works on the future point release. Could it be that the versioning is linked to that?
Seems strange if the Rocky repo shows el8, yet my Rocky unzip rpm also installed after Rocky 8.4 was installed with dnf shows el8_4. Repo inconsistencies maybe?
[root@rocky ~]# dnf remove unzip
Dependencies resolved.
========================================================================================================================================
Package Architecture Version Repository Size
========================================================================================================================================
Removing:
unzip x86_64 6.0-45.el8_4 @baseos 414 k
Removing dependent packages:
redhat-lsb x86_64 4.1-47.el8 @appstream 0
rpm-build x86_64 4.14.3-19.el8 @appstream 292 k
systemtap x86_64 4.5-3.el8 @appstream 0
Removing unused dependencies:
annobin x86_64 9.72-1.el8_5.2 @appstream 135 k
at x86_64 3.1.20-11.el8 @baseos 125 k
avahi x86_64 0.7-20.el8 @baseos 1.2 M
avahi-glib x86_64 0.7-20.el8 @baseos 16 k
bc x86_64 1.07.1-5.el8 @baseos 229 k
boost-atomic x86_64 1.66.0-10.el8 @appstream 8.6 k
boost-chrono x86_64 1.66.0-10.el8 @appstream 38 k
boost-date-time x86_64 1.66.0-10.el8 @appstream 78 k
boost-filesystem x86_64 1.66.0-10.el8 @appstream 111 k
boost-system x86_64 1.66.0-10.el8 @appstream 22 k
boost-thread x86_64 1.66.0-10.el8 @appstream 179 k
boost-timer x86_64 1.66.0-10.el8 @appstream 30 k
bzip2 x86_64 1.0.6-26.el8 @baseos 90 k
cups x86_64 1:2.2.6-40.el8 @appstream 6.7 M
cups-client x86_64 1:2.2.6-40.el8 @appstream 165 k
cups-filesystem noarch 1:2.2.6-40.el8 @appstream 0
cups-filters x86_64 1.20.0-27.el8 @appstream 2.4 M
cups-filters-libs x86_64 1.20.0-27.el8 @appstream 287 k
cups-ipptool x86_64 1:2.2.6-40.el8 @appstream 6.2 M
desktop-file-utils x86_64 0.23-8.el8 @appstream 246 k
dwz x86_64 0.12-10.el8 @appstream 225 k
dyninst x86_64 11.0.0-3.el8 @appstream 14 M
ed x86_64 1.14.2-4.el8 @baseos 128 k
efi-srpm-macros noarch 3-3.el8 @appstream 38 k
elfutils x86_64 0.185-1.el8 @baseos 2.7 M
elfutils-debuginfod-client-devel x86_64 0.185-1.el8 @baseos 8.9 k
elfutils-devel x86_64 0.185-1.el8 @baseos 171 k
esmtp x86_64 1.2-15.el8 @epel 100 k
ghc-srpm-macros noarch 1.4.2-7.el8 @appstream 414
ghostscript x86_64 9.27-1.el8 @appstream 38 k
go-srpm-macros noarch 2-17.el8 @appstream 7.2 k
libX11-xcb x86_64 1.6.8-5.el8 @appstream 7.4 k
libdrm x86_64 2.4.106-2.el8 @appstream 385 k
libesmtp x86_64 1.0.6-18.el8 @epel 160 k
libglvnd x86_64 1:1.3.2-1.el8 @appstream 777 k
libglvnd-glx x86_64 1:1.3.2-1.el8 @appstream 684 k
liblockfile x86_64 1.14-1.el8 @appstream 51 k
libpciaccess x86_64 0.14-1.el8 @baseos 45 k
libpng12 x86_64 1.2.57-5.el8 @appstream 449 k
libxshmfence x86_64 1.3-2.el8 @appstream 12 k
libzstd-devel x86_64 1.4.4-1.el8 @baseos 149 k
mailcap noarch 2.1.48-3.el8 @baseos 71 k
mailx x86_64 12.5-29.el8 @baseos 474 k
make x86_64 1:4.2.1-10.el8 @baseos 1.4 M
mesa-libGL x86_64 21.1.5-1.el8.0 @appstream 494 k
mesa-libGLU x86_64 9.0.0-15.el8 @appstream 453 k
mesa-libglapi x86_64 21.1.5-1.el8.0 @appstream 233 k
ncurses-compat-libs x86_64 6.1-9.20180224.el8 @baseos 1.0 M
ocaml-srpm-macros noarch 5-4.el8 @appstream 737
openblas-srpm-macros noarch 2-2.el8 @appstream 104
perl-Algorithm-Diff noarch 1.1903-9.el8 @baseos 108 k
perl-Archive-Tar noarch 2.30-1.el8 @baseos 151 k
perl-Archive-Zip noarch 1.60-3.el8 @appstream 254 k
perl-B-Lint noarch 1.20-11.el8 @appstream 30 k
perl-CGI noarch 4.38-2.el8 @appstream 538 k
perl-CPAN noarch 2.18-397.el8 @appstream 1.7 M
perl-CPAN-Meta noarch 2.150010-396.el8 @appstream 596 k
perl-CPAN-Meta-Requirements noarch 2.140-396.el8 @appstream 69 k
perl-CPAN-Meta-YAML noarch 0.018-397.el8 @appstream 51 k
perl-Class-ISA noarch 0.36-1022.el8 @appstream 13 k
perl-Compress-Bzip2 x86_64 2.26-6.el8 @appstream 147 k
perl-Compress-Raw-Bzip2 x86_64 2.081-1.el8 @baseos 57 k
perl-Compress-Raw-Zlib x86_64 2.081-1.el8 @baseos 143 k
perl-Data-Dump noarch 1.23-7.module+el8.4.0+529+e3b3e624 @appstream 50 k
perl-Data-OptList noarch 0.110-6.el8 @appstream 49 k
perl-Data-Section noarch 0.200007-3.el8 @appstream 42 k
perl-Devel-Size x86_64 0.81-2.el8 @appstream 42 k
perl-Digest-HMAC noarch 1.03-17.module+el8.4.0+529+e3b3e624 @appstream 11 k
perl-Digest-SHA x86_64 1:6.02-1.el8 @appstream 113 k
perl-Encode-Locale noarch 1.05-10.module+el8.4.0+529+e3b3e624 @appstream 19 k
perl-Env noarch 1.04-395.el8 @appstream 26 k
perl-ExtUtils-CBuilder noarch 1:0.280230-2.el8 @appstream 96 k
perl-ExtUtils-Command noarch 1:7.34-1.el8 @appstream 9.9 k
perl-ExtUtils-Install noarch 2.14-4.el8 @appstream 86 k
perl-ExtUtils-MM-Utils noarch 1:7.34-1.el8 @appstream 3.2 k
perl-ExtUtils-MakeMaker noarch 1:7.34-1.el8 @appstream 717 k
perl-ExtUtils-Manifest noarch 1.70-395.el8 @appstream 84 k
perl-ExtUtils-ParseXS noarch 1:3.35-2.el8 @appstream 181 k
perl-File-CheckTree noarch 4.42-303.el8 @appstream 28 k
perl-File-HomeDir noarch 1.002-4.el8 @appstream 118 k
perl-File-Listing noarch 6.04-17.module+el8.4.0+529+e3b3e624 @appstream 16 k
perl-File-Which noarch 1.22-2.el8 @appstream 24 k
perl-HTML-Parser x86_64 3.72-15.module+el8.4.0+529+e3b3e624 @appstream 223 k
perl-HTML-Tagset noarch 3.20-34.module+el8.4.0+529+e3b3e624 @appstream 19 k
perl-HTTP-Cookies noarch 6.04-2.module+el8.4.0+529+e3b3e624 @appstream 68 k
perl-HTTP-Date noarch 6.02-19.module+el8.4.0+529+e3b3e624 @appstream 19 k
perl-HTTP-Message noarch 6.18-1.module+el8.4.0+529+e3b3e624 @appstream 204 k
perl-HTTP-Negotiate noarch 6.01-19.module+el8.4.0+529+e3b3e624 @appstream 28 k
perl-IO-Compress noarch 2.081-1.el8 @baseos 792 k
perl-IO-HTML noarch 1.001-11.module+el8.4.0+529+e3b3e624 @appstream 42 k
perl-IO-Zlib noarch 1:1.10-420.el8 @baseos 19 k
perl-IPC-Cmd noarch 2:1.02-1.el8 @appstream 85 k
perl-IPC-System-Simple noarch 1.25-17.el8 @appstream 69 k
perl-JSON-PP noarch 1:2.97.001-3.el8 @appstream 127 k
perl-LWP-MediaTypes noarch 6.02-15.module+el8.4.0+529+e3b3e624 @appstream 61 k
perl-Locale-Codes noarch 3.57-1.el8 @appstream 2.3 M
perl-Locale-Maketext noarch 1.28-396.el8 @appstream 171 k
perl-Locale-Maketext-Simple noarch 1:0.21-420.el8 @appstream 14 k
perl-MRO-Compat noarch 0.13-4.el8 @appstream 25 k
perl-Math-BigInt noarch 1:1.9998.11-7.el8 @baseos 679 k
perl-Math-Complex noarch 1.59-420.el8 @baseos 86 k
perl-Module-Build noarch 2:0.42.24-5.el8 @appstream 654 k
perl-Module-CoreList noarch 1:5.20181130-1.el8 @appstream 848 k
perl-Module-Load noarch 1:0.32-395.el8 @appstream 14 k
perl-Module-Load-Conditional noarch 0.68-395.el8 @appstream 29 k
perl-Module-Metadata noarch 1.000033-395.el8 @appstream 66 k
perl-Module-Pluggable noarch 2:5.2-7.el8 @appstream 54 k
perl-Module-Runtime noarch 0.016-2.el8 @appstream 31 k
perl-NTLM noarch 1.09-17.module+el8.4.0+529+e3b3e624 @appstream 31 k
perl-Net-HTTP noarch 6.17-2.module+el8.4.0+529+e3b3e624 @appstream 75 k
perl-Net-Ping noarch 2.55-420.el8 @appstream 88 k
perl-Package-Generator noarch 1.106-11.el8 @appstream 30 k
perl-Params-Check noarch 1:0.38-395.el8 @appstream 28 k
perl-Params-Util x86_64 1.07-22.el8 @appstream 73 k
perl-Perl-OSType noarch 1.010-396.el8 @appstream 33 k
perl-Pod-Checker noarch 4:1.73-395.el8 @appstream 49 k
perl-Pod-Html noarch 1.22.02-420.el8 @appstream 36 k
perl-Pod-LaTeX noarch 0.61-302.el8 @appstream 84 k
perl-Pod-Parser noarch 1.63-396.el8 @appstream 263 k
perl-Pod-Plainer noarch 1.04-7.el8 @appstream 5.1 k
perl-Software-License noarch 0.103013-2.el8 @appstream 450 k
perl-Sub-Exporter noarch 0.987-15.el8 @appstream 139 k
perl-Sub-Install noarch 0.928-14.el8 @appstream 35 k
perl-Sys-Syslog x86_64 0.35-397.el8 @appstream 95 k
perl-Test-Harness noarch 1:3.42-1.el8 @appstream 567 k
perl-Test-Simple noarch 1:1.302135-1.el8 @appstream 1.2 M
perl-Text-Diff noarch 1.45-2.el8 @baseos 84 k
perl-Text-Glob noarch 0.11-4.el8 @appstream 8.6 k
perl-Text-Soundex x86_64 3.05-8.el8 @appstream 47 k
perl-Text-Template noarch 1.51-1.el8 @appstream 111 k
perl-Text-Unidecode noarch 1.30-5.el8 @appstream 449 k
perl-Time-HiRes x86_64 4:1.9758-2.el8 @appstream 114 k
perl-TimeDate noarch 1:2.30-15.module+el8.4.0+529+e3b3e624 @appstream 94 k
perl-Try-Tiny noarch 0.30-7.module+el8.4.0+529+e3b3e624 @appstream 65 k
perl-WWW-RobotRules noarch 6.02-18.module+el8.4.0+529+e3b3e624 @appstream 25 k
perl-XML-LibXML x86_64 1:2.0132-2.el8 @appstream 975 k
perl-XML-NamespaceSupport noarch 1.12-4.el8 @appstream 45 k
perl-XML-SAX noarch 1.00-1.el8 @appstream 121 k
perl-XML-SAX-Base noarch 1.09-4.el8 @appstream 173 k
perl-autodie noarch 2.29-396.el8 @appstream 211 k
perl-devel x86_64 4:5.26.3-420.el8 @appstream 3.4 M
perl-inc-latest noarch 2:0.500-9.el8 @appstream 35 k
perl-libwww-perl noarch 6.34-1.module+el8.4.0+529+e3b3e624 @appstream 505 k
perl-local-lib noarch 2.000024-2.el8 @appstream 117 k
perl-srpm-macros noarch 1-25.el8 @appstream 794
perl-version x86_64 6:0.99.24-1.el8 @appstream 125 k
poppler x86_64 20.11.0-3.el8 @appstream 3.7 M
poppler-data noarch 0.4.9-1.el8 @appstream 11 M
poppler-utils x86_64 20.11.0-3.el8 @appstream 681 k
psmisc x86_64 23.1-5.el8 @baseos 483 k
python-rpm-macros noarch 3-41.el8 @appstream 4.2 k
python-srpm-macros noarch 3-41.el8 @appstream 4.2 k
python3-pip noarch 9.0.3-20.el8.rocky.0 @appstream 2.8 k
python3-pyparsing noarch 2.1.10-7.el8 @baseos 519 k
python3-rpm-macros noarch 3-41.el8 @appstream 3.5 k
python3-setuptools noarch 39.2.0-6.el8 @baseos 450 k
python36 x86_64 3.6.8-38.module+el8.5.0+671+195e4563 @appstream 13 k
qpdf-libs x86_64 7.1.1-10.el8 @appstream 942 k
qt5-srpm-macros noarch 5.15.2-1.el8.0.1 @appstream 0
redhat-lsb-core x86_64 4.1-47.el8 @appstream 54 k
redhat-lsb-cxx x86_64 4.1-47.el8 @appstream 0
redhat-lsb-desktop x86_64 4.1-47.el8 @appstream 0
redhat-lsb-languages x86_64 4.1-47.el8 @appstream 814
redhat-lsb-printing x86_64 4.1-47.el8 @appstream 0
redhat-lsb-submod-multimedia x86_64 4.1-47.el8 @appstream 0
redhat-lsb-submod-security x86_64 4.1-47.el8 @appstream 0
redhat-rpm-config noarch 125-1.el8 @appstream 144 k
rust-srpm-macros noarch 5-2.el8 @appstream 1.1 k
spax x86_64 1.5.3-13.el8 @baseos 407 k
systemtap-client x86_64 4.5-3.el8 @appstream 11 M
systemtap-devel x86_64 4.5-3.el8 @appstream 8.8 M
systemtap-runtime x86_64 4.5-3.el8 @appstream 1.3 M
systemtap-sdt-devel x86_64 4.5-3.el8 @appstream 191 k
tbb x86_64 2018.2-9.el8 @appstream 411 k
time x86_64 1.9-3.el8 @baseos 84 k
util-linux-user x86_64 2.32.1-28.el8 @baseos 62 k
xdg-utils noarch 1.1.2-5.el8 @appstream 310 k
xz-devel x86_64 5.2.4-3.el8.1 @baseos 202 k
zip x86_64 3.0-23.el8 @baseos 808 k
zstd x86_64 1.4.4-1.el8 @appstream 1.5 M
Transaction Summary
========================================================================================================================================
Remove 184 Packages
Freed space: 109 M
Is this ok [y/N]: ^COperation aborted.
[root@rocky ~]# dnf reinstall unzip
Last metadata expiration check: 8:04:13 ago on Wed 17 Nov 2021 12:57:09 CET.
Installed package unzip-6.0-45.el8_4.x86_64 (from baseos) not available.
Error: No packages marked for reinstall.
seems I cannot remove it to try and get a sane system.
EDIT:
removed it and all those 180 packages, and installed unzip again.
[root@rocky ~]# rpm -qa | grep unzip
unzip-6.0-45.el8.x86_64
so definitely something happened between 8.4 and 8.5 with those package name mixups.
You could have tried dnf reinstall unzip
I’d guess that unzip-6.0-45.el8_4.x86_64 was an update released after release of RHEL 8.4.
Supported by Rocky 8.4 repo still having:
unzip-6.0-44.el8.x86_64.rpm 2021-05-19
unzip-6.0-45.el8_4.x86_64.rpm 2021-06-29
and for 8.5 the essentially same package was rebuild (as seen in Rocky 8.5 repo):
unzip-6.0-45.el8.x86_64.rpm 2021-11-09
Your dnf update did not see any reason to replace unzip-6.0-45.el8_4 with unzip-6.0-45.el8
I did once (CentOS Linux [45]?) remove zlib by mistake. Can’t remember whether yum did exist, but ‘rpm’ was practically dead after that. Had to reinstall from scratch. Good times …
I did, from my previous post quoted above. Package not available in baseos. Since this was available at one point, and then disappears only proves the repository inconsistencies, and the inability to upgrade a package, when the name has been changed to el8_4 instead of sticking with a standard like el8. An unzip el8_4 was pushed, then replaced later with el8 which then meant I couldn’t upgrade my packages without manually deleting and reinstalling once the repodata was cleaned out with dnf clean all.
Had the package continually had el8 this problem wouldn’t exist. I think as well for packages named with el8_5 then changing to el8 will also incur the same problem. Not good. Packages need to be upgradeable without having to uninstall them like I had to do above.
But, is there a real problem?
You said yourself that when a package with higher version appears, it will be upgraded to as expected.
If, and only if, contents (not metadata) of unzip-6.0-45.el8_4 and unzip-6.0-45.el8 differ, then there would be a problem.
I don’t have an answer to the question when and why a disttag with elX_Y is used, but I had a look at an installation of RHEL and both of these unzip packages are present, I don’t see a problem though.
# dnf list unzip --showduplicates
Updating Subscription Management repositories.
Last metadata expiration check: 0:47:57 ago on Wed 17 Nov 2021 21:43:37 CET.
Available Packages
unzip.x86_64 6.0-41.el8 rhel-8-for-x86_64-baseos-rpms
unzip.x86_64 6.0-43.el8 rhel-8-for-x86_64-baseos-rpms
unzip.x86_64 6.0-44.el8 rhel-8-for-x86_64-baseos-rpms
unzip.x86_64 6.0-45.el8 rhel-8-for-x86_64-baseos-rpms
unzip.x86_64 6.0-45.el8_4 rhel-8-for-x86_64-baseos-rpms
the changelogs look similar
# rpm -qp --changelog unzip-6.0-45.el8.x86_64.rpm |head
* Tue Nov 24 2020 Jakub Martisko <jamartis@redhat.com> - 6.0-45
Fix a false positive zipbomb detection
Related: 1954649
Related: 1953565
* Tue Nov 24 2020 Jakub Martisko <jamartis@redhat.com> - 6.0-44
* Fix out of memory errors while checking for zip-bombs
Resolves: #1900915
* Mon Nov 18 2019 Jakub Martisko <jamartis@redhat.com> - 6.0-43
# rpm -qp --changelog unzip-6.0-45.el8_4.x86_64.rpm |head
* Tue Nov 24 2020 Jakub Martisko <jamartis@redhat.com> - 6.0-45
Fix a false positive zipbomb detection
Related: 1954649
Related: 1953565
Related: 1969876
Resolves: 1970326
* Tue Nov 24 2020 Jakub Martisko <jamartis@redhat.com> - 6.0-44
* Fix out of memory errors while checking for zip-bombs
Resolves: #1900915
As I understand it, a package labelled X_Y (eg el8_4) means it has a dependency on X.Y (eg 8.4) or later.
It’s very common for a RedHat server to have a mixture of package versions.
eg looking at my local CentOS “BaseOS + AppStream” mirror (I haven’t bothered to do a local Rocky mirror… yet!) I see
7717 el8
5 el8_0
25 el8_1
8 el8_2
15 el8_3
123 el8_4
148 el8_5One example is zsh-5.5.1-6.el8_1.2.x86_64.rpm. So if you install zsh on an 8.5 machine then the package will have the el8_1 version. This doesn’t mean you have an old version; it’s still the latest and greatest version.
I wouldn’t call these inconsistencies, per say. This is normal behavior, even for upstream. There are cases where you’ll still see 8_* packages even when you’re on a newer release because that package isn’t getting an update. What I can show you is this:
This is how sometimes these things occur. In terms of our current system, it is treating that unzip import as the latest, even though technically el8_4 is the latest, and so that is what got pushed out. This isn’t the first time that has happened unfortunately. This is something we’re keeping an eye on as we get the next build system ready.
I can do some retagging and get that fixed and get updates pushed out. I’ll be looking around to see if there are others. If anyone notices anything, let us know and we’ll take a look.
Doh! Should have realized that “6.0-45.el8” != “6.0-45.el8_4” for the reinstall.
Clearly, “6.0-45.el8_4” < “6.0-45.el8” is false, or dnf up would have acted.
That implies that, at least for dnf syntax, the “6.0-45.el8” < “6.0-45.el8_4” is true.
Then dnf downgrade unzip-6.0-45.el8 might have been ok as a command.
What is the dnf distro-sync that migration discussions have mentioned?
They also show that patches for both have been applied the same day (2020-11-24).
Presumably RHEL main development branch had unzip-6.0-44.el8 at some point. Lets call it “Stream”.
Then RH did branch RHEL-8.4 from Stream. It got unzip-6.0-44.el8.
After that both branches were patched:
Later, RH did branch RHEL-8.5 from Stream. It got the unzip-6.0-45.el8 from Stream.
RH deems it sufficient for new adopters?
Given all that, does unzip-6.0-45.el8_4 → unzip-6.0-45.el8 look like downgrade, no-op, or upgrade?
I only have this:
[root@rocky ~]# dnf distro-sync
Last metadata expiration check: 0:00:08 ago on Thu 18 Nov 2021 09:04:35 CET.
Dependencies resolved.
Nothing to do.
Complete!
Prior to that ran:
dnf update --refresh
Anyway all is OK right now, there are only a few 8_4 packages installed now. As long as everything updates OK without problems/conflicts then all is good 
was mostly after clarification for why that way rather than incrementing the package minor version number and if there is any advantage/disadvantage of doing it that way.