Bug 1717117

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.

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.

Created attachment 1579094 [details]
Journalctl from the installation of 20190604 compose

Created attachment 1579095 [details]
Journalctl from the installation of 20190609 compose

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.

(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.

*** Bug 1719373 has been marked as a duplicate of this bug. ***

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.

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.

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)...

But default modules are NOT enabled. Does it mean EVERYONE should disable those modules explicitly if they want to use their  systems?

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.

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.

There is nothing I can do from modules side. bat module does not have broken dependencies. Libgit2 neither.

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.

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.

(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.

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.

*** Bug 1719729 has been marked as a duplicate of this bug. ***

(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.

*** Bug 1719864 has been marked as a duplicate of this bug. ***

*** Bug 1718646 has been marked as a duplicate of this bug. ***

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.

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.

> 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!

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

(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/.

A blog post by Adam Samalik, for some context:
https://communityblog.fedoraproject.org/modularity-vs-libgit/

*** Bug 1720022 has been marked as a duplicate of this bug. ***

-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.

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

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

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

Problem is reported against fc30 and still relevant to this release.

I got an information that all issues related to modularity should be redirected to distribution component, changing component.

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This issue was mitigated by banning default streams in Fedora <https://docs.fedoraproject.org/en-US/modularity/policies/>. No streams since Fedora 32 are default.

Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.