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
Hi there, Thanks for the deep-dive. What does this mean for us (the Zeek build maintainers)? Your analysis would seem to affect anyone building for CentOS Stream 8 who happens to pull in that dependency, and https://bugzilla.redhat.com/show_bug.cgi?id=2102548 doesn't seem to be going anywhere. Is OBS going to weigh in on those tickets? Also, if dnf does not care about the repo split, is that fact usable for us? Best, Christian
Hi Christian, First of all, I'm nothing more than an openSUSE contributor who happened to see someone, in the IRC room, pointing out this unpleasant issue for CentOS Stream 8 repositories, and decided to take a closer look of what's going on. So, I can't speak on behalf of OBS admins if they are going to take any course of actions towards this issue. If I were in your shoes (and anyone who stumpled upon this issue), for any package OBS ends up with unresolvable like those for glibc* and cmake* I'd would open an upstream bug. And since there's already one for glibc, I'd pop a comment in there. Sooner or later the CentOS/Red Hat folks would have to act upon it. It doesn't seem like something really hard to do from where I sit, but who knows.
Also, if dnf does not care about the repo split, is that fact usable for us?
Maybe. Maybe not. I'm not sure about that. I'm not familiar with OBS's code base (I don't even really know Ruby/Pearl) so I can't say how exactly it does look for packages (I'm almost sure it involves parsing the repo medatada somehow) and how hard/easy would be to implement DNF's logic of "OK, Pkg A requires Pkg B and Pkg B comes from the same spec file as Pkg A, so let's have look in Repo Foo. Ah, found Pkg A in Repo Foo! Pkg B must be here somewhere then ... Can't find it here in Repo Foo, so let's look in Repo Bar ... Ah, found it!". Perhaps opening an issue in OBS's GH repo and discussing possibilities wouldn't hurt. Cheers, Luciano
Am 27.10.22 um 03:35 schrieb Luciano Santos:
It took a bit of a discussion in #opensuse-buildservice and some digging up. So let's see what's going on.
Thank you very much for clearing this up! I am struggling with the very same topic here: https://build.opensuse.org/package/show/home:behrisch/sumo Is there any plausible workaround? Can we do something obs magic using the project config? Best regards, Michael
Michael Behrisch wrote:
Thank you very much for clearing this up! I am struggling with the very same topic here: https://build.opensuse.org/package/show/home:behrisch/sumo Is there any plausible workaround? Can we do something obs magic using the project config? Best regards, Michael
No, maybe someone else know something I don't, but I don't see any. Specially because we're talking about a distribution that uses DoD - download on demand - instead of hosting the packages in OBS itself. You could trying hosting the problematic packages in your repository, like that CMake and any other that gets an unresolvable. I don't know how many packages had issues with that repo splitting, so I can't say how practical this solution would be. If we're talking about a few packages, this could work. The best solution is still to get CentOS to fix their repos. Kind regards, Luciano
participants (3)
-
Christian Kreibich -
Luciano Santos -
Michael Behrisch