Bug 1717117 - Can't install module libgit2:0.28 due to (uninstalled) conflicts
Summary: Can't install module libgit2:0.28 due to (uninstalled) conflicts
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: rawhide
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
Keywords:
: 1718646 1719373 1719729 1719864 1720022 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-04 17:54 UTC by Josh Stone
Modified: 2019-07-15 18:55 UTC (History)
37 users (show)

(edit)
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)
Journalctl from the installation of 20190604 compose (568.62 KB, text/plain)
2019-06-10 16:43 UTC, Lukas Ruzicka
no flags Details
Journalctl from the installation of 20190609 compose (580.07 KB, text/plain)
2019-06-10 16:43 UTC, Lukas Ruzicka
no flags Details

Description Josh Stone 2019-06-04 17:54:51 UTC
Description of problem:
I am unable to install module libgit2:0.28 due to conflicts with the bat, silver, and exa modules, even though I don't have those installed or enabled at all.

Version-Release number of selected component (if applicable):
dnf-4.2.5-1.fc30.noarch

How reproducible:
100%

Steps to Reproduce:
1. dnf module list libgit2 bat exa silver
   (make sure none are enabled yet)
2. sudo dnf module install libgit2:0.28

Actual results:

$ dnf module list libgit2 bat exa silver
Last metadata expiration check: 0:02:33 ago on Tue 04 Jun 2019 10:43:56 AM PDT.
Fedora Modular 30 - x86_64
Name            Stream              Profiles            Summary
bat             latest [d]          default [d]         cat(1) clone with wings
exa             latest [d]          default [d]         Modern replacement for ls
libgit2         0.26                                    Library implementation of Git
libgit2         0.27 [d]                                Library implementation of Git
libgit2         0.28                                    Library implementation of Git

Fedora Modular 30 - x86_64 - Updates
Name            Stream              Profiles            Summary
bat             latest [d]          default [d]         cat(1) clone with wings
exa             latest [d]          default [d]         Modern replacement for ls
libgit2         0.26                                    Library implementation of Git
libgit2         0.27 [d]                                Library implementation of Git
libgit2         0.28                                    Library implementation of Git
silver          rolling [d]         default [d]         Cross-shell customizable powerline-like prompt with icons

Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

$ sudo dnf module install libgit2:0.28
Last metadata expiration check: 1:24:13 ago on Tue 04 Jun 2019 09:21:12 AM PDT.
Error: Problems in request:
broken groups or modules: libgit2:0.28
Modular dependency problems:

 Problem 1: conflicting requests
  - module bat:latest:3020190424130937:552c3bf4-0.x86_64 requires module(libgit2:0.27), but none of the providers can be installed
  - module libgit2:0.27:3020190304180745:a5b0195c-0.x86_64 conflicts with module(libgit2:0.28) provided by libgit2:0.28:3020190304210604:a5b0195c-0.x86_64
  - module libgit2:0.28:3020190304210604:a5b0195c-0.x86_64 conflicts with module(libgit2:0.27) provided by libgit2:0.27:3020190304180745:a5b0195c-0.x86_64
 Problem 2: module silver:rolling:3020190505102338:552c3bf4-0.x86_64 requires module(libgit2:0.27), but none of the providers can be installed
  - module libgit2:0.27:3020190304180745:a5b0195c-0.x86_64 conflicts with module(libgit2:0.28) provided by libgit2:0.28:3020190407181355:a5b0195c-0.x86_64
  - module libgit2:0.28:3020190407181355:a5b0195c-0.x86_64 conflicts with module(libgit2:0.27) provided by libgit2:0.27:3020190304180745:a5b0195c-0.x86_64
  - conflicting requests
 Problem 3: module exa:latest:3020190424131210:552c3bf4-0.x86_64 requires module(libgit2:0.27), but none of the providers can be installed
  - module libgit2:0.27:3020190304180745:a5b0195c-0.x86_64 conflicts with module(libgit2:0.28) provided by libgit2:0.28:3020190304210604:a5b0195c-0.x86_64
  - module libgit2:0.28:3020190304210604:a5b0195c-0.x86_64 conflicts with module(libgit2:0.27) provided by libgit2:0.27:3020190304180745:a5b0195c-0.x86_64
  - conflicting requests

Expected results:
Able to install libgit2:0.28 -- knowing that the other packages won't be possible to install too.

Additional info:

Comment 1 Lukas Ruzicka 2019-06-10 16:03:21 UTC
Hello, 

I have experienced similar problems, but during an installation of Fedora Rawhide. However, the behaviour is quite interesting. 

* The compose was Workstation-boot-iso-x86_64-BuildFedora-Rawhide-20190604.n.0. 
* When installed on Production Server of OpenQA, it did not run into that problem, see https://openqa.fedoraproject.org/tests/408926.
* When installed today on Staging Server (which basically should mimick the Production server) I ran into the following problem: https://openqa.stg.fedoraproject.org/tests/555934, especially this slide - https://openqa.stg.fedoraproject.org/tests/555934#step/_boot_to_anaconda/15

The logs from the affected system are here: https://openqa.stg.fedoraproject.org/tests/555934#downloads. 

I will also consult this with Adam, to check whether the problems are at our place.

Comment 2 Lukas Ruzicka 2019-06-10 16:42:27 UTC
Also tried to test this and the latest compose locally, but they ended up with the same error about conflicting packages (see Comment 1). 
The journals are added, the error is seen almost at the end of the journal file. For deeper logs, check the OpenQA link I have posted above.

Comment 3 Lukas Ruzicka 2019-06-10 16:43 UTC
Created attachment 1579094 [details]
Journalctl from the installation of 20190604 compose

Comment 4 Lukas Ruzicka 2019-06-10 16:43 UTC
Created attachment 1579095 [details]
Journalctl from the installation of 20190609 compose

Comment 5 Jaroslav Mracek 2019-06-10 19:09:12 UTC
It looks like that bat, silver in update testing/rawhide 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.

Comment 6 Igor Gnatenko 2019-06-11 15:44:18 UTC
(In reply to Jaroslav Mracek from comment #5)
> It looks like that bat, silver in update testing/rawhide 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.

Please read first comment in this bugzilla. Josh does not have any of them installed. He explicitly uninstalled all of them and disabled streams.

Comment 7 Igor Gnatenko 2019-06-11 15:46:51 UTC
*** Bug 1719373 has been marked as a duplicate of this bug. ***

Comment 8 Tomas Tomecek 2019-06-11 16:08:06 UTC
Joining the party, same problem:

$ dnf --enablerepo=\*testing\* module enable pretty-git-prompt
Modular dependency problems:

 Problem 1: module bat:latest:3020190608081801:3494d9fa-0.x86_64 requires module(libgit2:0.28), but none of the providers can be installed
  - module libgit2:0.28:3020190304210604:a5b0195c-0.x86_64 conflicts with module(libgit2:0.27) provided by libgit2:0.27:3020190304180745:a5b0195c-0.x86_64
  - module libgit2:0.27:3020190304180745:a5b0195c-0.x86_64 conflicts with module(libgit2:0.28) provided by libgit2:0.28:3020190304210604:a5b0195c-0.x86_64
  - module libgit2:0.28:3020190407181355:a5b0195c-0.x86_64 conflicts with module(libgit2:0.27) provided by libgit2:0.27:3020190304180745:a5b0195c-0.x86_64
  - module libgit2:0.27:3020190304180745:a5b0195c-0.x86_64 conflicts with module(libgit2:0.28) provided by libgit2:0.28:3020190407181355:a5b0195c-0.x86_64
  - module libgit2:0.28:3020190606170438:a5b0195c-0.x86_64 conflicts with module(libgit2:0.27) provided by libgit2:0.27:3020190304180745:a5b0195c-0.x86_64
  - module libgit2:0.27:3020190304180745:a5b0195c-0.x86_64 conflicts with module(libgit2:0.28) provided by libgit2:0.28:3020190606170438:a5b0195c-0.x86_64
  - module bat:latest:3020190424130937:552c3bf4-0.x86_64 requires module(libgit2:0.27), but none of the providers can be installed
  - conflicting requests

I also don't have the bat module enabled.

Comment 9 Jaroslav Mracek 2019-06-11 16:59:08 UTC
To resolve the conflict just disable problematic modules "dnf module disable bat silver exa". The conflict can be seen because modules `bat` `silver` `exa` have a default stream, therefore they are handled as enabled.

Comment 10 Kostya Vasilyev 2019-06-11 17:09:01 UTC
RE: just disable problematic modules

Is there going to be a "proper" fix later?

I have no idea what these "module" things are and would like the error to go away "on its own" (= i.e. getting fixed)...

Comment 11 Igor Gnatenko 2019-06-11 17:09:43 UTC
But default modules are NOT enabled. Does it mean EVERYONE should disable those modules explicitly if they want to use their  systems?

Comment 12 Petr Pisar 2019-06-12 07:34:03 UTC
IMHO there is not a big difference between default and enabled stream when resolving modular dependencies. Both are handled as active modules. Primarily the default stream should no have broken dependencies. Bodhi should prevent from pushing them into any compose. Maintainers of the broken streams should fix them.

However, DNF could handle broken modular dependencies better. E.g. as it handles packages with unsatisfied RPM dependencies. Just report them and skip them.

Comment 13 Jaroslav Mracek 2019-06-12 08:10:49 UTC
Thanks Petr for your comment. For module operation that are not allowed due to broken dependency you can try --skip-broken option.

Also according to comment 12 I would like to kindly ask a maintainer of modules bat, exa and silver to revert the last changes, because it brakes Fedora. Thanks a lot for understanding and cooperation because it is the only solution at the present time.

Comment 14 Igor Gnatenko 2019-06-12 08:46:29 UTC
There is nothing I can do from modules side. bat module does not have broken dependencies. Libgit2 neither.

Comment 15 Igor Gnatenko 2019-06-12 10:55:14 UTC
Just to elaborate more on this:

* libgit2:0.27 is the default
* libgit2:0.28 is available
* bat:rolling is the default
* bat:rolling depends on libgit2:0.28

As long as you don't have anything dependent on libgit2:0.27, bat:rolling should be installable without any problems. Default streams are NOT enabled which means they can conflict with each other.

Comment 16 Petr Pisar 2019-06-12 11:09:43 UTC
No. Default streams are forbidden to depend on non-default streams. That's the assumption DNF works with. I don't say that's the best state of affairs but it's how DNF is supposed to work.

Comment 17 Igor Gnatenko 2019-06-12 11:16:13 UTC
(In reply to Petr Pisar from comment #16)
> No. Default streams are forbidden to depend on non-default streams. That's
> the assumption DNF works with. I don't say that's the best state of affairs
> but it's how DNF is supposed to work.

Speaking with my Modularity WG hat on, I don't think anybody agreed to prohibit this. And I don't agree that this is *desired* behavior. I'm pretty sure it is NOT.

Comment 18 Petr Pisar 2019-06-12 11:36:46 UTC
All default streams are active at the same time. This is a basic goal of Modularity.

If you create default A:1 stream that requires B:1, and a default C:1 stream that requires B:2, there is no way how to satisfy both A:1 and C:1 streams at the same time. Yet both A:1 and C:1 are default. This contradicts to the goal.

That implies all default streams must be compatible each to other. And that grounds the statement that all default streams can depend only on the default streams. Technically it's too strong requirement because we could arrange dependencies on non-default streams in a way that they would not conflict, but that would precluded adding new default streams. Hence the requirement is material.

Comment 19 Igor Gnatenko 2019-06-12 12:41:12 UTC
*** Bug 1719729 has been marked as a duplicate of this bug. ***

Comment 20 Igor Gnatenko 2019-06-12 13:20:06 UTC
(In reply to Petr Pisar from comment #18)
> All default streams are active at the same time. This is a basic goal of
> Modularity.

No, the goal is to be able to install content from those streams without explicitly enabling modules. When content gets installed, respective modules get enabled. So unless you are trying to install foo.rpm from one default module together with bar.rpm from another default module which conflict, nothing should complain.

Comment 21 Igor Gnatenko 2019-06-12 21:52:26 UTC
*** Bug 1719864 has been marked as a duplicate of this bug. ***

Comment 22 Igor Gnatenko 2019-06-13 06:19:14 UTC
*** Bug 1718646 has been marked as a duplicate of this bug. ***

Comment 23 Igor Gnatenko 2019-06-13 06:22:27 UTC
From the other bug:

> The latest changes in exa, silver, bat in downstream must be reverted. It makes very bad picture about quality of Fedora.

Because of the poor DNF implementation of modularity, yes.

> Additionally rebuild of latest version of exa, silver, bat against libgit 0.27 could also help.

I have no way of doing that. rust-git2 is now on 0.28, I have to use 0.28 or stop shipping updates.

> The problem is also that default streams are used. There must be a rule that default stream must not create a conflict.

As I explained earlier this is b$%^&!@t, default streams are not enabled so they can conflict. Yes, this can prevent from *enabling* or *installing* 2 modules which are in conflict, but this is fine.

> I would like to kindly ask you Igor whatever you can fix the distribution or you will keep it broken?

I'm waiting on ETA from you folks (DNF team) to provide an ETA for this fix.

Comment 24 Jaroslav Mracek 2019-06-13 10:47:18 UTC
The statement from DNF folks:

Last changes in downstream must be reverted, right now. Then we have to look for options. The first part is on you Igor.

Comment 25 Josh Stone 2019-06-13 16:49:34 UTC
> rust-git2 is now on 0.28, I have to use 0.28 or stop shipping updates.

FWIW, most of the upstream work I did to update crates for this was just a version bump, no code changes. So if we must, it may not be all that horrible to patch those dependencies back down to the prior version of rust-git2. But this isn't a long-term solution, of course!

Comment 26 Brian Lane 2019-06-13 17:48:05 UTC
We're hitting this in the lorax rawhide tests, here -- https://travis-ci.org/weldr/lorax/builds/544392663

Modular dependency problem:
 Problem: 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 tokei:rolling:3120190424130518:c3f9a127-0.x86_64 requires module(libgit2:0.27), but none of the providers can be installed
  - conflicting requests
Package sudo-1.8.27-1.fc31.x86_64 is already installed.
Error: 
 Problem: conflicting requests
  - package libgit2-glib-0.28.0.1-2.fc31.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed
  - package libgit2-glib-0.28.0.1-2.fc31.i686 requires libgit2.so.28, but none of the providers can be installed
  - package libgit2-glib-0.28.0.1-2.fc31.i686 requires libgit2(x86-32) >= 0.25.0, but none of the providers can be installed
  - package libgit2-0.28.2-1.module_f31+4568+116cccf1.x86_64 is excluded
  - package libgit2-0.28.2-1.fc31.i686 is excluded
  - package libgit2-0.28.2-1.fc31.x86_64 is excluded

Comment 27 Igor Gnatenko 2019-06-13 20:46:06 UTC
(In reply to Jaroslav Mracek from comment #24)
> The statement from DNF folks:
> 
> Last changes in downstream must be reverted, right now. Then we have to look
> for options. The first part is on you Igor.

I did not ask for an advise what to do. I asked about ETA for the fix from DNF side.

---

Also I've posted some thoughts on https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YRHVY55V6E3LWHMGXNZDU7QCHWOSHKGK/.

Comment 28 Michal Domonkos 2019-06-14 10:31:00 UTC
A blog post by Adam Samalik, for some context:
https://communityblog.fedoraproject.org/modularity-vs-libgit/

Comment 29 Martin Kolman 2019-06-14 11:51:56 UTC
*** Bug 1720022 has been marked as a duplicate of this bug. ***

Comment 30 Stephen Gallagher 2019-07-15 13:22:42 UTC
-1 blocker. It doesn't actually violate any criteria that I can find (broken deps are not individually enough to be a blocker). I could be +1 FE for Beta if the compat-package workaround discussed in the FESCo ticket misses the Beta Freeze date though.

Comment 31 Geoffrey Marr 2019-07-15 18:55:26 UTC
Discussed during the 2019-07-15 blocker review meeting: [1]

The decision to classify this bug as a "RejectedBlocker" was made as at the moment nothing about this seems to be violating any release criteria, it only results in an annoying error message showing up all the time, and a non-essential module not being installable. This is acceptable for Beta. We will re-propose it as a Final blocker in case it's not fixed by then.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-07-15/f31-blocker-review.2019-07-15-16.05.txt

Comment 32 Geoffrey Marr 2019-07-15 18:55:52 UTC
Discussed during the 2019-07-15 blocker review meeting: [1]

The decision to classify this bug as a "RejectedBlocker" was made as at the moment nothing about this seems to be violating any release criteria, it only results in an annoying error message showing up all the time, and a non-essential module not being installable. This is acceptable for Beta. We will re-propose it as a Final blocker in case it's not fixed by then.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-07-15/f31-blocker-review.2019-07-15-16.05.txt


Note You need to log in before you can comment on or make changes to this bug.