Bug 1718646
| Summary: | Modular dependency problems involving libgit2, bat, exa, silver, tokei in F30 [tokei module has not been rebuilt for libgit2 0.28] | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matt Fagnani <matt.fagnani> |
| Component: | dnf | Assignee: | rpm-software-management |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | awilliam, bugzilla, dmach, extras-orphan, igor.raits, iweiss, jmracek, jrohel, mblaha, mhatina, packaging-team-maint, pkratoch, psabata, robatino, rpm-software-management, sanjay.ankur, sgallagh, vmukhame, yaneti |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | openqa | ||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-06-13 06:19:14 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1644937 | ||
|
Description
Matt Fagnani
2019-06-09 16:06:09 UTC
Whatever it is is bug in DNF. OK thanks Igor. I have the following dnf rpms installed. dnf-0:4.2.5-1.fc30.noarch dnf-data-0:4.2.5-1.fc30.noarch dnf-plugins-core-0:4.0.7-1.fc30.noarch dnf-yum-0:4.2.5-1.fc30.noarch libdnf-0:0.31.0-3.fc30.x86_64 python3-dnf-0:4.2.5-1.fc30.noarch python3-dnf-plugins-core-0:4.0.7-1.fc30.noarch python3-libdnf-0:0.31.0-3.fc30.x86_64 It looks like that bat in update testing is build only with `libgit2: [0.28]`, but older version requires `libgit2: [0.27]`. It is impossible to enable content of multiple streams at the same time, therefore the behavior is correct. We have to improve a distribution to predict such a problems. I don't think that's quite it. We have various modules listed here: libgit2 itself, bat, exa, silver, and tokei. From the look of the logs, there are versions of the bat, exa and silver modules in play that work with libgit 0.27 *and* versions that work with 0.28. So those modules shouldn't be the problem - they should be able to agree on one or other version of the libgit2 module. I think the problem here is tokei. If you search the output for 'tokei', you will see that *only* a version for libgit 0.27 is shown. It seems the tokei module has not been rebuilt for version 0.28 of the libgit2 module. So I think what's going on here is 'dnf update' wants to pull in a newer version of one or more out of libgit2, bat, exa, and silver...but it's failing, because to do so it needs to pull in libgit2 0.28, but there is no version of the (installed) tokei module that works with it. So it gives up and complains. Note, I believe this is also currently affecting (and breaking) Rawhide. If you try a fresh install of Rawhide right now it fails because of this tokei vs. libgit2 issue: https://openqa.stg.fedoraproject.org/tests/556624#step/_boot_to_anaconda/15 Also, just doing *any* dnf operation on current Rawhide is enough to make it complain about this, although it's only informational in that case (the operation does continue and complete): [adamw@adam bodhi (develop %)]$ sudo dnf search foo [sudo] password for adamw: Modular dependency problems: Problem 1: module libgit2:0.28:3120190606170438:f636be4b-0.x86_64 conflicts with module(libgit2:0.27) provided by libgit2:0.27:3120190407181414:f636be4b-0.x86_64 - module libgit2:0.27:3120190407181414:f636be4b-0.x86_64 conflicts with module(libgit2:0.28) provided by libgit2:0.28:3120190606170438:f636be4b-0.x86_64 - module silver:rolling:3120190608092801:36e279aa-0.x86_64 requires module(libgit2:0.28), but none of the providers can be installed - conflicting requests Problem 2: module libgit2:0.28:3120190606170438:f636be4b-0.x86_64 conflicts with module(libgit2:0.27) provided by libgit2:0.27:3120190407181414:f636be4b-0.x86_64 - module libgit2:0.27:3120190407181414:f636be4b-0.x86_64 conflicts with module(libgit2:0.28) provided by libgit2:0.28:3120190606170438:f636be4b-0.x86_64 - module exa:latest:3120190608082828:36e279aa-0.x86_64 requires module(libgit2:0.28), but none of the providers can be installed - module tokei:rolling:3120190424130518:c3f9a127-0.x86_64 requires module(libgit2:0.27), but none of the providers can be installed - conflicting requests ============================================ Name & Summary Matched: foo ============================================= ... So, this is a problem. It also seems wrong that anaconda apparently immediately bails on this conflict in the default modules without checking whether it's actually going to *need* anything from them. I suspect it doesn't really need anything from the tokei module, at least for the default package set. Moving to tokei module. Hmm, actually it seems I'm partly wrong there: there really is an issue even with bat, exa and silver, because their default streams require the older libgit2. However, that seems to be tracked at https://bugzilla.redhat.com/show_bug.cgi?id=1717117 . Is it OK for this bug to keep being about tokei not having been rebuilt at all? > Is it OK for this bug to keep being about tokei not having been rebuilt at all?
Well, I'm not going to rebuild it against 0.28 because it is not yet ready for it. That was the whole point about modularity, not? Providing multiple versions so when some apps are not ready for switch, they still can consume old version.
---
I think the original reported in this bug meant more that he has kf5-ktexteditor depending on libgit2.so.27() while for some reason DNF is trying to do some weird things and complaining about not being able to install 0.27 and 0.28 installed at the same time.. Though, nobody is asking DNF to do that.
---
Said that, if you want a bug opened on tokei for rebuild on 0.28 of libgit, please open a new bugreport and I will handle it within few weeks.
Oh yes, good point. Should we close this as a dupe of the other then, or is there a reason to keep it open separately? The latest changes in exa, silver, bat in downstream must be reverted. It makes very bad picture about quality of Fedora. Additionally rebuild of latest version of exa, silver, bat against libgit 0.27 could also help. The problem is also that default streams are used. There must be a rule that default stream must not create a conflict. I would like to kindly ask you Igor whatever you can fix the distribution or you will keep it broken? (In reply to Adam Williamson from comment #8) > Oh yes, good point. Should we close this as a dupe of the other then, or is > there a reason to keep it open separately? I was thinking if there are 2 different bugs.. But after more thinking it is probably just one. *** This bug has been marked as a duplicate of bug 1717117 *** |