Re: nothing provides cmake-filesystem(x86-64) = 3.20.2-4.el8 needed by cmake when trying to compile for CentOS Stream 8
unresolvable: nothing provides glibc(x86-64) = 2.28-203.el8 needed by glibc-gconv-extra, (got version 2.28-214.el8 provided by glibc), nothing
It took a bit of a discussion in #opensuse-buildservice and some digging up. So let's see what's going on. In security:zeek project we can see this message for CentOS 8 Stream repository: provides glibc-common = 2.28-203.el8 needed by glibc-gconv-extra, (got version 2.28-214.el8) Please remember that our CentOS 8 Stream repository uses http://mirror.centos.org/centos/8-stream/ for package download, and that the AppStream repo takes precedence over BaseOS. First, let's check the version 2.28-203 for glibc, because that's the latest release that AppStream got:
$ curl -sLI http://mirror.centos.org/centos/8-stream/AppStream/x86_64/os/Packages/glibc-... | head -1 HTTP/1.1 404 Not Found curl -sLI http://mirror.centos.org/centos/8-stream/AppStream/x86_64/os/Packages/glibc-... | head -1 HTTP/1.1 200 OK
$ curl -sLI http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/glibc-2.2... | head -1 HTTP/1.1 200 OK $ curl -sLI http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/glibc-gco... | head -1 HTTP/1.1 404 Not Found
Here we can see that glibc-gconv-extra, a sub-package ofglibc, found in BaseOS, got split and is found in Appstream instead. OBS/openSUSE/many-other-RPM-based-distros(I believe) doesn't support a Package A being required by its Sub-Package B when A comes from Vendor/repo X and B, from Vendor/repo Y. DNF doesn't seem to share such restrictions, though, as seen here [1] in this bug report. And those missing glib (and possibly others) RPMs from mirror.centos.org are a result of an official decision to move certain packages from one repository to another (as stated in that bug report), but it seems that the move wasn't completed/successful, at least from my perspective of having Package A living in repo X being required by its Sub-Package B living in repo Y. Now, if the BaseOS repo takes precedence over AppStream we can find both 2.28-214 glibc and glibc-gconv-extra packages there:
$ fc curl -sLI http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/glibc-2.2... | head -1 curl -sLI http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/glibc-gco... | head -1 HTTP/1.1 200 OK HTTP/1.1 200 OK
Nonetheless, with BaseOS being above AppStream we get the unresolvable reported in this thread:
unresolvable: nothing provides cmake-filesystem(x86-64) = 3.20.2-4.el8 needed by cmake, (got version 3.20.2-1.el8 provided by cmake-filesystem)
That's because in BaseOS we can find another Package/Sub-Package missing:
$ curl -sLI http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/cmake-3.2... | head -1 HTTP/1.1 404 Not Found curl -sLI http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/cmake-fil... | head -1 HTTP/1.1 200 OK
A cmake-filesystem-3.20.2-1 that wants a not found cmake-3.20.2-1. And in AppStream:
$ curl -sLI http://mirror.centos.org/centos/8-stream/AppStream/x86_64/os/Packages/cmake-... | head -1 HTTP/1.1 200 OK $ curl -sLI http://mirror.centos.org/centos/8-stream/AppStream/x86_64/os/Packages/cmake-... | head -1 HTTP/1.1 200 OK
Both packages are there, but since we're prioritizing BaseOS and one of them was already found, we end up with an unresolvable. In BaseOS we don't have a 3.20.2-4 CMake release (which would take precedence over 3.20.2-1), only in Appstream:
$ curl -sLI http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/cmake-3.2... | head -1 HTTP/1.1 404 Not Found $ curl -sLI http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/cmake-fil... | head -1 HTTP/1.1 404 Not Found
$ curl -sLI http://mirror.centos.org/centos/8-stream/AppStream/x86_64/os/Packages/cmake-... | head -1 HTTP/1.1 200 OK $ curl -sLI http://mirror.centos.org/centos/8-stream/AppStream/x86_64/os/Packages/cmake-... | head -1 HTTP/1.1 200 OK
But, again, since we're prioritizing BaseOS and one of them was already found, we end up with an unresolvable. The right way forward, I'd say, is to file bugs for those missing packages and/or add comments to existing bugs, like the one for glibc. Cheers, Luciano [1] https://bugzilla.redhat.com/show_bug.cgi?id=2102548
participants (1)
-
Luciano Santos