As a workaround, I've tried to do `dnf module disable libgit2` but it fails with "module exa:latest:3020190306064823:e50d0d19-0.x86_64 requires module(libgit2:0.27)"

So I had to do the following:

1. dnf module disable libgit2 exa bat
2. dnf remove exa
3a. dnf install exa -- that fails with "no match for argument exa"
3b. dnf module install exa

That pulled nonmodular libgit2_0.28 and the problem is gone. However the workaround is tedious and now I had to explicitly install a module - something that should not be needed to get exa.

yet another DNF "correct behavior", reassigning.

Related: https://bugzilla.redhat.com/show_bug.cgi?id=1717117

Related thread from the fedora-devel:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/GUH4T2NHYCVSZHLMLABMEYMZCPCYRQSM/

The problem probably is, that libgit2 changed it's default stream between f30 and f31.

That problem was solved by providing libgit in a nonmodular package.

The actual problem here is dnf prevents me from installing the nonmodular package: "package libgit2-0.28.2-3.fc31.x86_64 is excluded".

I think this is a design problem, where modular packages are preventing me from doing stuff that previously worked.

I tried:

sudo dnf --releasever 31 --installroot /tmp/testing6 install exa --nogpgcheck 
sudo dnf --releasever 31 --installroot /tmp/testing6 --nogpgcheck --enablerepo=updates-testing distro-sync
sudo dnf --releasever 31 --installroot /tmp/testing6 install bat --nogpgcheck 
sudo dnf --releasever 31 --installroot /tmp/testing6 --nogpgcheck --enablerepo=updates-testing distro-sync

and I was unable to discover any issue.

I suggest that you previously enabled libgit-2 with stream 0.27, therefore the absence of packages from stream 0.28 is logical. I also believe that the issue could be resolved by `dnf module reset libgit2 exa bat`.

According to Comment 5 "That problem was solved by providing libgit-2 in a non-modular package." it looks like that the problem in Fedora 31 was only partially fixed. To resolve it completely libgit-2 module must have no default stream. Default stream works like enabled stream therefore it prevents from consummation of non-modular packages.

Please could maintainers of libgit-2 remove a default stream from Fedora 31? Otherwise the problem of libgit-2 reappears during system-upgrade?

I had exactly the same issue on my Fedora 30 when I run:
  dnf --releasever=31 --setopt=deltarpm=false --setopt=module_platform_id=platform:f31 --enablerepo=updates-testing --disableplugin=needs-restarting --disableplugin=tracer distro-sync
But after running `dnf module reset libgit2 exa bat` this error disappeared. The only cause I can think of is that when I was upgrading from F29 to F30 I had to manually fiddle with libgit2 because of bug (?) 1717117.

More details:

# dnf module list libgit2 exa bat
....
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][e]                                                       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][e]                                                       Library implementation of Git                     
libgit2                       0.28                                                              Library implementation of Git                     


# dnf module reset libgit2 exa bat
....
Závislosti vyřešeny.
==================================================================================================================================================
 Balíček                            Architektura                      Verze                              Repozitář                          Velikost
==================================================================================================================================================
Resetting modules:
 libgit2                                                                                                                                         

Shrnutí transakce
==================================================================================================================================================

Je to ok [a/N]: a
Hotovo!


# dnf module list libgit2 exa bat
...
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                     

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


I.e. no change so far. But before `module reset` I experienced the error. While after `module reset` which does not change anything visible, the error disappeared and I can upgrade without this error.

Another person hit by this: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7N7NI3V3QGLJNYWT4XAN4SNW2OGGHYCP/

I'm proposing this as a blocker. I don't know if this meets any formal criteria, but it will prevent upgrades for a huge amount of users.

When this only hit command-line applications, I thought, okay, at least people who've installed those will be comfortable fixing it from the command line. However, it also touches several graphical applications, so I don't think it'd be acceptable to let this languish. I'm not sure whether this meets Blocker criteria, but it at least ups the priority in my mind.

kf5-ktexteditor is required by kate, the KDE text editor. gnome-builder, and gitg are also GUI applications.

 Problem 5: problem with installed package R-git2r-0.26.1-1.fc30.x86_64
  - package R-git2r-0.26.1-3.fc31.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed
  - R-git2r-0.26.1-1.fc30.x86_64 does not belong to a distupgrade repository
  - package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is excluded
  - package libgit2-0.28.2-3.fc31.x86_64 is excluded
 Problem 6: problem with installed package bat-0.10.0-1.module_f30+4037+f98ba4b0.x86_64
  - package bat-0.11.0-3.module_f31+5338+1c55392b.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed
  - bat-0.10.0-1.module_f30+4037+f98ba4b0.x86_64 does not belong to a distupgrade repository
  - package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is excluded
  - package libgit2-0.28.2-3.fc31.x86_64 is excluded
 Problem 14: problem with installed package git-time-metric-1.3.5-2.fc30.x86_64
  - package git-time-metric-1.3.5-4.fc31.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed
  - git-time-metric-1.3.5-2.fc30.x86_64 does not belong to a distupgrade repository
  - package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is excluded
  - package libgit2-0.28.2-3.fc31.x86_64 is excluded
 Problem 15: problem with installed package gnome-builder-3.32.2-1.fc30.x86_64
  - package gnome-builder-3.34.0-1.fc31.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed
  - package gnome-builder-3.33.92-1.fc31.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed
  - gnome-builder-3.32.2-1.fc30.x86_64 does not belong to a distupgrade repository
  - package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is excluded
  - package libgit2-0.28.2-3.fc31.x86_64 is excluded
 Problem 17: problem with installed package kf5-ktexteditor-5.59.0-1.fc30.x86_64
  - package kf5-ktexteditor-5.61.0-1.fc31.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed
  - kf5-ktexteditor-5.59.0-1.fc30.x86_64 does not belong to a distupgrade repository
  - package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is excluded
  - package libgit2-0.28.2-3.fc31.x86_64 is excluded
 Problem 18: package gitg-libs-3.32.1-1.fc31.x86_64 requires libgit2-glib-1.0.so.0()(64bit), but none of the providers can be installed
  - problem with installed package gitg-libs-3.30.1-3.fc30.x86_64
  - package libgit2-glib-0.28.0.1-3.fc31.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed
  - libgit2-glib-0.27.8-1.fc30.x86_64 does not belong to a distupgrade repository
  - gitg-libs-3.30.1-3.fc30.x86_64 does not belong to a distupgrade repository
  - package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is excluded
  - package libgit2-0.28.2-3.fc31.x86_64 is excluded
 Problem 19: package gitg-3.32.1-1.fc31.x86_64 requires gitg-libs(x86-64) = 3.32.1-1.fc31, but none of the providers can be installed
  - package gitg-libs-3.32.1-1.fc31.x86_64 requires libgit2-glib(x86-64) >= 0.28.0, but none of the providers can be installed
  - problem with installed package gitg-3.30.1-3.fc30.x86_64
  - package libgit2-glib-0.28.0.1-3.fc31.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed
  - gitg-3.30.1-3.fc30.x86_64 does not belong to a distupgrade repository
  - package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is excluded
  - package libgit2-0.28.2-3.fc31.x86_64 is excluded

Proposed as a Blocker for 31-beta by Fedora user pwalter using the blocker tracking app because:

 Cannot upgrade to Fedora 31

So, users who dnf install exa or bat now won't eb affected. In roger to reproduce ona  clean Fedora 30, you need to:

dnf module enable libgit2:0.27
dnf install libgit2
dnf install exa bat
dnf system-upgrade download --release=31

Error: 
 Problem 1: problem with installed package bat-0.10.0-1.module_f30+3530+914c400d.x86_64
  - package bat-0.11.0-3.module_f31+5338+1c55392b.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed
  - bat-0.10.0-1.module_f30+3530+914c400d.x86_64 does not belong to a distupgrade repository
  - package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is excluded
  - package libgit2-0.28.2-3.fc31.x86_64 is excluded
 Problem 2: problem with installed package exa-0.8.0-1.module_f30+3531+1e7e6552.x86_64
  - package exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed
  - exa-0.8.0-1.module_f30+3531+1e7e6552.x86_64 does not belong to a distupgrade repository
  - package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is excluded
  - package libgit2-0.28.2-3.fc31.x86_64 is excluded

> So, users who dnf install exa or bat now won't eb affected. In roger to reproduce ona  clean Fedora 30, you need to:

Let me type that again:

So, users who dnf install exa or bat now won't be affected. In order to reproduce on a clean Fedora 30, you need to:

Discussed at the Fedora 31 Beta Go/No-Go Meeting #1, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2019-09-12/f31-beta-go_no_go-meeting.2019-09-12-17.00.txt . This was rejected as a Beta blocker as the criterion covers only upgrades of the default package sets for release-blocking editions, and no release-blocking default package set is affected by this problem so far as we can tell. Leaving Final blocker proposal open for now.

Should we add 'dnf module reset libgit2' to fedora-obsolete-packages %post ?

fedora-obsolete-packages %post happens after this error prevents to upgrade to Fedora 31. Unless we add it to Fedora 30. But it can break systems with explicitly selected modular streams.

Right, we would need to add it in F30. But we can do this. I guess this should be conditionalized
somehow, e.g. to check if libgit2 module was enabled implicitly as a dependency or implicitly by
the user.

Discussed during the 2019-09-16 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker" and an "AcceptedFreezeException" was made for the same reason we rejected it for Beta: it does not affect any release-blocking default package set, so does not break the criteria. But it's definitely a bad bug and we'd like it resolved if at all possible, and documented if it is not resolved, therefore we grant it a Freeze Exception.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-09-16/f31-blocker-review.2019-09-16-16.02.txt

Nominating as a Prioritized Bug[0] due to the impact on a key Fedora feature

[0] https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues_-_the_process

I've posted a proposal to make this a FESCo blocker: https://pagure.io/fesco/issue/2230

> @ignatenkobrain That's actually a really good idea as a short-term workaround. It doesn't solve the full problem (we want to stay locked on the stream if it was explicitly selected), but it's probably good enough for the F30->F31 upgrade.
> @psabata and @langdon  What do you think about this strategy?

This sound like hack that is completely out of concept of modularity. I believe that one of primary feature was to provide alternative content with fixed API across distribution releases.

I'd rather have a completely hacked concept of modularity than broken upgrades. But I understand that others have different priorities than me and this is a selfish opinion.

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

Well, even it is hack, it is up to us to decide if we want it or not.

I think for Fedora, where we have just a few modules and few streams and is still kinda "tech preview", it is fine to just reset old default to the new default when upgrading.

And after all, it is just for one release. I saw that Langdon is proposing improvements in this area for F32, so this should be fixed by then.

Reassigning bug since there is definitely nothing I can do as a module maintainer.

FYI

I put this workaround to fedora-upgrade-31.2. But this is an unofficial upgrade tool.

For a moment I thought about resetting all modules:
  dnf module reset $(dnf module list 2>/dev/null|grep '\[\d\]\[e\]' | grep -v '\[x\]' | awk '{print $1}'|sort|uniq)
but then I backup to minimal change and just reset those three.

And I altered https://fedoraproject.org/wiki/Upgrading_Fedora_using_package_manager#Fedora_31

I will leave it to others to do something with official upgrade tools.

There's also nothing we can do in DNF until modularity specs change.

The only possible workaround at the moment is executing:
$ dnf module reset '*'
prior running the system upgrade as suggested in comment#25

This is a bug. I don't care whether it is a dnf bug, libgit2 bug or a modularity bug, but don't just close it without a fix please.

Setting whiteboard to AcceptedBlocker per
https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Automatic_blockers
https://pagure.io/fesco/issue/2230#comment-599678

Also setting the version to 31 so it shows up in https://qa.fedoraproject.org/blockerbugs

(In reply to Miro Hrončok from comment #27)
> This is a bug. I don't care whether it is a dnf bug, libgit2 bug or a
> modularity bug, but don't just close it without a fix please.

Ok then. I suppose that as long as this bug is an accepted blocker, Fedora cannot be released.
Since the fix cannot be made in DNF, reassigning to distribution so the issue can be documented or fixed somewhere else.

If modularity specs change, we'll work on changing DNF accordingly,
but I don't think it's doable in F31 time frame.

In fact, I think this can be **workarounded** in the upgrade part of dnf (dnf-system-upgrade?), it can provide an actionable error message. For example:

------

Error: The following modules have dependency problems when upgrading: exa, bat, libgit2.

You can try running the following before the upgrade to workaround the problem:

    dnf module reset exa bat libgit2

Be aware that this might change the stream of the exa, bat and libgit2 modules, for more information, see https://bugzilla.redhat.com/show_bug.cgi?id=1747408

------

Obviously, this is a hack, but way bettar than the current error.

The GNOME Software variant of the upgrade process might need a separate workaround.

I think the proper fix for this bug is to remove the default stream (and, IMHO, all other streams) of the affected packages and force the use of one default version.

Modularity is unfixable by design and this can never be fixed as long as we keep shipping libraries as modules.

To be clear, I mean, one default non-modular version.

I would like to ask Modularity people for participation on the discussion.

I would propose to remove default stream for libgit2. It at least prevents the same problem in future. Please could you also consider it as a solution?
Is there any plan for change of policy for stream defaults?

This bug is no caused by having a default stream of libgit2.

(In reply to Kevin Kofler from comment #32)
> To be clear, I mean, one default non-modular version.

Yes, I support this idea. I have already said that somewhere, but I think we should provide the defaults as a "non-modular" content in Fedora and enable the users to opt-in for whatever module and stream they decide. We should never force modularity onto users, or at least until everything has been correctly designed, implemented, and tested! It is not fair to speak about "technology preview" on Fedora and ship default streams that make people's systems into modular systems without their consent. This is NOT how technology preview behaves. A tech preview always is an "opt-in" thing.


I also think that DNF could provide more information on update and upgrade errors that are caused by someone being locked in a non-default specific stream, so that they could choose how they are going to fix it for them.

(In reply to Lukas Ruzicka from comment #36)
> (In reply to Kevin Kofler from comment #32)
> > To be clear, I mean, one default non-modular version.
> 
> Yes, I support this idea. I have already said that somewhere, but I think we
> should provide the defaults as a "non-modular" content in Fedora and enable
> the users to opt-in for whatever module and stream they decide. We should
> never force modularity onto users, or at least until everything has been
> correctly designed, implemented, and tested! It is not fair to speak about
> "technology preview" on Fedora and ship default streams that make people's
> systems into modular systems without their consent. This is NOT how
> technology preview behaves. A tech preview always is an "opt-in" thing.

Amen. However, even if we make this so, how do we fix this mess?

(In reply to Jaroslav Mracek from comment #33)
> I would like to ask Modularity people for participation on the discussion.

This is an AcceptedBlocker and a PrioritizedBug. 10 days have passed and there was no answer. This only supports the statement that we should have never forced modularity onto users, when there is nobody who would actually fix the critical problems.

See also my message on devel that proposes a simple solution to this longterm problem: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LPKSMMJY2KD347PBKNNEIUNL2GVJCV3W/

Too late to implement in F31, so an immediate dirty workaround still needs to be invented here. I've proposed such in comment #30:

> Error: The following modules have dependency problems when upgrading: exa,
> bat, libgit2.
> 
> You can try running the following before the upgrade to workaround the
> problem:
> 
>     dnf module reset exa bat libgit2
> 
> Be aware that this might change the stream of the exa, bat and libgit2
> modules, for more information, see
> https://bugzilla.redhat.com/show_bug.cgi?id=1747408

DNF and modularity team agreed that system-upgrade will provide a link where user could easily find a solution for system-upgrade. The URL will be taken from "/etc/os-release". It means that the solution will require release of fedora-release and dnf-plugin-system-upgrade packages into Fedora 29 and 30. No additional update will be required for Fedora 31. 

At the present time following links are available in os-release:

DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f30/system-administrators-guide/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"

From DNF perspective:
1. DNF team will implement parsing of os-release file and providing information to user at the begging of run of "dnf system-upgrade download".
2. What key we have to look for in os-release file?
3. DNF upstream is not going to maintain content of web page about system-upgrade issues (requires community interaction).

How will the message with the link look?

Proposing following fix: https://github.com/rpm-software-management/dnf-plugins-extras/pull/162.

It still requires the proper information in os-release.

What is the plan with system upgrades done through gnome-software? This pull request only adds the message to dnf, but not to gnome-software.

So the proposed workaround dis to do this?

$ sudo dnf system-upgrade
Additional information for System Upgrade: <url>
...
...
problem with installed package exa-0.8.0-13.module_f30+4041+ebfd9240.x86_64
  - package exa-0.9.0-2.module_f31+5365+04413d87.x86_64 requires libgit2.so.28()(64bit), but none of the providers can be installed
  - exa-0.8.0-13.module_f30+4041+ebfd9240.x86_64 does not belong to a distupgrade repository
  - package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is excluded
  - package exa-0.9.0-3.fc31.x86_64 is excluded
  - package libgit2-0.28.2-3.fc31.x86_64 is excluded




How is that helpful exactly?

The <url> is supposed to provide a knowledge base for known issues for particular system-upgrade. The content of the page is up to community of the particular distribution.

(In reply to Jaroslav Mracek from comment #42)
> https://github.com/rpm-software-management/dnf-plugins-extras/pull/162.
> It still requires the proper information in os-release.

This PR looks for DOCUMENTATION_URL= in os-release. Fedora has had
that field populated for many years (possibly from the very introduction
of that file). So if the plan is to look for DOCUMENTATION_URL=, there is
no need to add anything.

But that doesn't solve the issue raised in comment #c44 — displaying this
URL does very little to help the user.

If instead the plan is to add a new field to os-release, then as a maintainer
of systemd which "owns" this file, I don't think this is a good idea. All
the fields in that file are supposed to be generic, and we shouldn't just
add fields there, unless there's evidence that they make sense outside of
just a single distribution and a single tool.

For some context: the Modularity team and the DNF team met on Friday to discuss potential solutions to the problem. We determined that the proper and complete solution (being worked out on the devel list) is not achievable in the remaining time for Fedora 31's development. We then looked towards ways we could mitigate the problem. We discussed several different approaches, but ultimately I suggested that the path of minimal difficulty would be to update the DNF system-upgrade message to include a link to an upgrade guide that will include instructions on how to work around the module upgrade bug. This requires minimal changes to DNF and only a small change to fedora-release to include the new URL field.


DOCUMENTATION_URL is a relatively recent addition to /etc/os-release. See https://github.com/systemd/systemd/pull/10270

It was actually added primarily for tools like Cockpit to provide a web link to documentation.

I would have suggested linking to the Common Bugs page in the SUPPORT_URL= field, except we already have that going to https://fedoraproject.org/wiki/Communicating_and_getting_help (which conspicuously does not include a link to the Common Bugs page currently).

From os-release(5): "Operating system vendors may extend the file format and introduce new fields. It is highly recommended to prefix new fields with an OS specific name in order to avoid name clashes."

So we have two options here: We could add this field as something like FEDORA_UPGRADE_GUIDE_URL= or we could come up with a more suitable name for generic use and I'll propose that upstream. I think the latter makes more sense, so does anyone have a problem with me suggesting UPGRADE_GUIDE_URL= as a new field upstream? If so, let's go with FEDORA_UPGRADE_GUIDE_URL= just to support this workaround.

I would prefer UPGRADE_GUIDE_URL. The prefix FEDORA_ makes the code unusable by other distributions. DNF is not a Fedora project, but Fedora is one of distributions that is shipped with DNF.

UPGRADE_GUIDE_URL= is not bad.

But really, is sending the user off to a manual that describes the upgrade process in general
the best we can come up with? Shouldn't dnf instead say something about 'dnf module reset'?

Could libdnf automatically reset all modules during distro upgrades, so that gnome-software can also benefit from the fix?

I don't consider displaying a generic link **at a beginning of the upgrade process** as a proper hint. The user is **buffled by the cryptic error message at the end of the log**. They need to receive a pointer at that point. Since we are cooking an ugly workaround here, the pointer can very well be hardcoded (pseudo code):

  if error matches "package libgit2-\S+ is excluded":
      echo "You are hit by a common bug, execute dnf module reset and retry the upgrade, see <common bugs links>"


I also second that the gnome-software upgrade way needs this too.

PS Sorry for saying nobody was looking into this. It wasn't quite clear that there was a dnf/modularity meeting on Friday.

+1 that whatever we do needs to cover GNOME Software, and it needs to be prominent. I share Miro's concern about *where* and *when* this note appears - by the time you see the error, the note will be several thousand lines deep in scrollback, I believe.

(In reply to Adam Williamson from comment #52)
> +1 that whatever we do needs to cover GNOME Software, and it needs to be
> prominent. I share Miro's concern about *where* and *when* this note appears
> - by the time you see the error, the note will be several thousand lines
> deep in scrollback, I believe.

For the record, we're talking about the statement you have to agree to *before* DNF starts pulling down metadata and packages. Where it currently reminds you to make sure you have all updates on the current release before attempting to update.

That said, I agree that this is probably not a sufficient solution for GNOME Software (and probably other tools that are less release-blocking but still important).

(In reply to Kalev Lember from comment #50)
> Could libdnf automatically reset all modules during distro upgrades, so that
> gnome-software can also benefit from the fix?

I don't think we can do that, because libdnf doesn't actually know when it's doing a distro-upgrade vs. a standard package update (unless I'm mistaken, in which case please tell me). We *definitely* don't want libdnf resetting all streams for all updates.

Also, resetting *all* streams is probably overzealous, since it would result in contradicting intentional user decisions. (This is why my proposal on the devel list[1] includes recording the reason for stream enablement in the future). Furthermore, not all streams are affected by this.

I wonder if we could have libdnf attempt two passes though: see if the upgrade can proceed without stream conflicts and do so if it can. If it cannot, try a second pass overriding a subset of problem streams (libgit2, exa) with their default stream and see if the update would succeed that way (possibly requiring a second user confirmation?)

Again, please keep in mind that this is not intended to be read as a proper solution. We're just trying to unblock F31 enough that we can fix this properly in F32.

"For the record, we're talking about the statement you have to agree to *before* DNF starts pulling down metadata and packages. Where it currently reminds you to make sure you have all updates on the current release before attempting to update."

Yeah, but, think through how a regular user experiences the whole upgrade process. I agree with Miro here.

At the time they initially run `dnf system-upgrade download` - the time when they'll see the message - they are not aware that something is about to go wrong. Now I'm a QA person so I confidently expect any and all software to blow up fifteen different ways as soon as I look at it, so I *might* pay attention to some message about some documentation that popped up at this stage. But do you think most users will? I suspect they won't. As long as something is proceeding the way you expect it to, text that pops up is there to be impatiently skimmed over and clicked through. Do we really expect a significant amount of people to go "hmm, maybe I *should* click on this link and read everything it says before continuing with the upgrade"? Cos, well, that seems optimistic.

Otherwise, what the experience is going to feel like to them is "run command, words words words whatever *hit y*, wait thirty minutes for everything to download, oh crap now it blew up! What the hell does "package libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is excluded" mean?"

I think it's reasonable to be concerned that encountering the generic "hey go read this documentation!" message some time *before* they hit the bug just isn't going to be enough.

(In reply to Miro Hrončok from comment #51)
> Since we are cooking an ugly workaround here, the pointer can very
> well be hardcoded (pseudo code):
> 
>   if error matches "package libgit2-\S+ is excluded":
>       echo "You are hit by a common bug, execute dnf module reset and retry
> the upgrade, see <common bugs links>"

I agree with this approach. This could be downstream patch and just for F31, because we are going to have the right fix for F32+, right?

Moreover, because I believe there is known the small subset of modules which suffers this issue, it could even be:

~~~
   if error matches "package (libgit2|exa)-\S+ is excluded":
      exec("dnf module reset ...")
~~~

ad UPGRADE_GUIDE_URL=  -- this is 3rd document user should check. `fedora-upgrade(8)` already suggests checking

 * http://docs.fedoraproject.org/f${TARGET_VERSION}/release-notes/
 * https://fedoraproject.org/wiki/Common_F${TARGET_VERSION}_bugs

It is not terrible to add 3rd document, but not good as well.

> That said, I agree that this is probably not a sufficient solution for GNOME Software

Than GNOME Software should fix it. DNF is not a garbage bin for developers with statements "it will not be visible in $FOO, can DNF team fix that for us".

(In reply to Stephen Gallagher from comment #53)
> (In reply to Kalev Lember from comment #50)
> > Could libdnf automatically reset all modules during distro upgrades, so that
> > gnome-software can also benefit from the fix?
> 
> I don't think we can do that, because libdnf doesn't actually know when it's
> doing a distro-upgrade vs. a standard package update (unless I'm mistaken,
> in which case please tell me). We *definitely* don't want libdnf resetting
> all streams for all updates.

PackageKit calls hy_goal_distupgrade_all() for distro upgrades and hy_goal_upgrade_to() for standard package updates, so libdnf should already have the information which of the two operations it is doing.

If that isn't enough, could always add new libdnf API so that the callers could explicitly tell libdnf before depsolving that they are doing a distro upgrade.

(In reply to Adam Williamson from comment #54)
> "For the record, we're talking about the statement you have to agree to
> *before* DNF starts pulling down metadata and packages. Where it currently
> reminds you to make sure you have all updates on the current release before
> attempting to update."
> 
> Yeah, but, think through how a regular user experiences the whole upgrade
> process. I agree with Miro here.
> 
> At the time they initially run `dnf system-upgrade download` - the time when
> they'll see the message - they are not aware that something is about to go
> wrong. Now I'm a QA person so I confidently expect any and all software to
> blow up fifteen different ways as soon as I look at it, so I *might* pay
> attention to some message about some documentation that popped up at this
> stage. But do you think most users will? I suspect they won't.

I can *guarantee* you that I will not, and almost nobody does, unless they have
done something special to their distro on their own and know that thing breaks
updates, and even then ...

Certainly nobody expects upgrade to break when they did *nothing* special at all
unless people here can say with a straight face that a yum install done in F30
that somehow pulled in a module unbeknownst to the user is "something special".

> As long as
> something is proceeding the way you expect it to, text that pops up is there
> to be impatiently skimmed over and clicked through. Do we really expect a
> significant amount of people to go "hmm, maybe I *should* click on this link
> and read everything it says before continuing with the upgrade"? Cos, well,
> that seems optimistic.
> 
> Otherwise, what the experience is going to feel like to them is "run
> command, words words words whatever *hit y*, wait thirty minutes for
> everything to download, oh crap now it blew up! What the hell does "package
> libgit2-0.28.2-2.module_f31+5411+fa1856a4.x86_64 is excluded" mean?"
> 
> I think it's reasonable to be concerned that encountering the generic "hey
> go read this documentation!" message some time *before* they hit the bug
> just isn't going to be enough.

Expecting users to *fix* this after the *distribution* broke it is frankly an
unacceptable user experience.

The user is expressing a clear intention when running "yum system-upgrade", the user
wants to upgrade the system, so it is entirely *reasonable* to reset the modules to
the defaults when the user expresses that intent.

If we are concerned that in some case this operation *may* go against an explicit
user action *then* we call out at yum system-upgrade that this upgrade operation
may result in some module being reset to the default.
In other words, you treat specially and give special instructions for the special case,
*not* the common case.

The *common* case should just work, and the *common* case here is obviously modules
have been pulled in unintentionally and now we need to deal with it.

If you think otherwise I would like to have a chat in person with you, whoever you
are, to better explain why that is the case, because if that is what you think I think
there is a huge misalignment of expectations, and that needs to b corrected before any
progress can be made (and to avert disaster).

HTH.

> Also, resetting *all* streams is probably overzealous, since it would result in contradicting intentional user decisions.

Let's be real here, how many Fedora people will suffer from a reset stream compared to the ones that will suffer from  failed upgrades ?

It's 80/20 time here. Modules are used by very few, tech preview, and fundamentally not ready.

It is totally reasonable to have a bump for module users, rather than breaking fedora upgrades for *a lot more users*.

It is even more so if you consider that users of modules are in a much better position to understand how to switch to
the module they had selected than it is for normal users that do not know what modules are to learn how to fix the upgrade.

If all the reasons *not* to reset module on system-upgrades are "but someone may have chosen a module intentionally" then I see no good reason sorry, the breakage is overwhelmingly more severe than catering for those 2 users that chose  to use a tech-preview feature and will have really no problems fixing it after the fact.

Thanks all for nice discussion. Be honest we did not move anywhere. I want to resolve the issue and I feel a personal responsibility for development of modularity in DNF upstream and DNF Fedora downstream.

What I know:
1. Currently the issue is only related to limited number of modules - axa, bat, libgit2 
2. The behavior change of "dnf system-upgrade" and PackageKit must be deployed to Fedora 29, 30, but it also affect other system upgrades paths (Upgrade to Fedora30, 32).
3. Solution in DNF (work-arround)
    a. Documentation updates
    b. Resetting of all modules automatically
4. Other solutions for PackageKit
    This is topic for another bugzilla and will require code changes in PackageKit like adding support of modules.
5. Permanent solution
    So far it is unknown. Proposed solutions are unacceptable for DNF. The solution must be also acceptable for RHEL and other distributions.

I know that broken upgrade path of 3 modules is sad but can distribution be blocked by problem with upgrade path of 3 modules? The answer should be same as for rpms that are not in minimal installation. (Personally I do not recognize it as a blocker or it is a blocker type like Fail-Safe (See: https://bugzilla.redhat.com/show_bug.cgi?id=1616167))

I also have a problem with solution b. "resetting of all modules". This is something against Modularity example 2. See https://docs.fedoraproject.org/en-US/modularity/.

> I know that broken upgrade path of 3 modules is sad but can distribution be blocked by problem with upgrade path of 3 modules?

Yes. The upgrade problems occur for people who have installed Kate or GNOME Builder. They have never opted in for modules at all.
So let me rephrase the question:


Should upgrade path problems of users who have opted in for modules block the release? No.

Should design flaws in modularity that break upgrades for people who have never opted in for modules block the release? Yes.



I propose that we stop arguing whether this is a blocker and implement a viable workaround. Resetting libgit2 and all modules that (used to) depend on the libgit2 module seems like one.

Resetting of all modules is probably drastic to our modular users, but it solves the problem for the majority of others. It can be a documented caveat.

(In reply to Miroslav Suchý from comment #25)
> FYI
> 
> I put this workaround to fedora-upgrade-31.2. But this is an unofficial
> upgrade tool.
> 
> For a moment I thought about resetting all modules:
>   dnf module reset $(dnf module list 2>/dev/null|grep '\[\d\]\[e\]' | grep
> -v '\[x\]' | awk '{print $1}'|sort|uniq)
> but then I backup to minimal change and just reset those three.
> 
> And I altered
> https://fedoraproject.org/wiki/
> Upgrading_Fedora_using_package_manager#Fedora_31
> 
> I will leave it to others to do something with official upgrade tools.

Interestingly, the unofficial tool got the proper workaround in no time.

https://github.com/xsuchy/fedora-upgrade/commit/35baf9d60fbd57c18da48ce068392ffcb8a0df90

Yet for the official tool, this requires endless discussions.

> 1. Currently the issue is only related to limited number of modules - axa, bat, libgit2 
Yes. That is why we can apply a simple pattern based solution that will solve 99% of cases.
*If* modularity was more widely used, something more complicated would be needed, but it's
not.

> 2. The behavior change of "dnf system-upgrade" and PackageKit must be deployed to Fedora 29, 30,
> but it also affect other system upgrades paths (Upgrade to Fedora30, 32).
I think the usage of modules in F29 is much smaller. The biggest concern is update from F30 to F31,
since this is what the most of *users* are doing. We can effectively ignore rawhide for this
discussion.

> 3. Solution in DNF (work-arround)
Yes, please implement it in DNF and push to F30.
I think we would want to reset those modules unconditionally, and never show show an error to the
the user, but I don't know enough about dnf to say if this is the most appropriate solution.

This is totally OK if this is an ugly downstream patch. This bug is only about Fedora.
I'm sure every "big" Fedora package has had at times patches to solve Fedora-specific
issues. That's part of what being a part of the distro is. Long-term "correct" solution
might be different, but we need something to fix the upgrade issues which will start
popping *next week* after we release F31.

Once dnf implements a solution, gnome-software will need to reimplement the same thing.
But once it is clear *what* is to be done, I hope repeating the same thing in g-s will
be easy.

Miro: well, yeah, because the unofficial tool is *unofficial*, and maintained by one person. So he can just decide to do whatever he wants and do it. It reflects only on that tool and that person.

This is about how to address the issue in our *official* tools, where whatever we decide reflects on the whole of Fedora as a project. That means more people care and want to debate it, and it's harder to come to a conclusion that most of them will agree on or at least accept.

That's kinda the nature of collaboration, really. You can always do things faster if you're not doing it. :)

FWIW, I'm in favour of just resetting affected modules as part of the upgrade process, whatever the details of implementing that are.

(In reply to Adam Williamson from comment #64)
> Miro: well, yeah, because the unofficial tool is *unofficial*, and
> maintained by one person. So he can just decide to do whatever he wants and
> do it. It reflects only on that tool and that person.
> 
> This is about how to address the issue in our *official* tools, where
> whatever we decide reflects on the whole of Fedora as a project. That means
> more people care and want to debate it, and it's harder to come to a
> conclusion that most of them will agree on or at least accept.
> 
> That's kinda the nature of collaboration, really. You can always do things
> faster if you're not doing it. :)

Fair point. But who's going to make the ultimate decision here? This is a blocker after all, we cannot debate this forever.

DNF team provided updated dnf-plugin-system-upgrade (https://bodhi.fedoraproject.org/updates/FEDORA-2019-daa0986c6d) that will show link from os-release. To resolve the issue it only requires to provide url in os-release file. Changing component.

Showing a link from os-release does not fix this bug. Neither it provides significant enough workaround.

A FESCo vote whether the proposed workaround is sufficient to unlock the release: https://pagure.io/fesco/issue/2230#comment-604516

Assigning back to distribution, as said in https://pagure.io/fesco/issue/2230#comment-604633 the DNF team cannot fix gnome-software. The same logic applies to the fedora-release package.

Please do not reassign the component yet again if not agreed upon.

Jaroslav also proposed an alternate solution:

> What about alternative solution?
> Modules axa, bat will be built not only with libgit2:0.28, but also with libgit2:0.26. This also resolves the issue.

Could you please elaborate?

1. What does it mean to build the exa and bat modules against both libgit2:0.26 and libgit2:0.28?
2. How does this resolve the bug for exa/bat users?
3. How does this resolve the bug for Kat/GNOME Builder users?

Why the problem happened?
F30:
Module "libgit2" has default stream "0.27"
Module "exa" requires: libgit2: [0.27], but later on the requirement was dropped.
Packages exa in Fedora 30 requires libgit2.so.27()(64bit), libgit2.so.28()(64bit).
Provider of libgit2.so.27()(64bit) is modular package "libgit2" from module libgit2:0.27.
Providers of libgit2.so.28()(64bit) 
1. non-modular compat package "libgit2_0.28".
2. Modular libgit2 from from module libgit2:0.28

F31:
Module "libgit2" has no default stream
Module "exa" does not require libgit2 module
Packages exa in Fedora 30 requires  libgit2.so.28()(64bit).
Providers of libgit2.so.28()(64bit) - non-modular libgit2 and modular libgit2 from module libgit2:0.28
When module libgit2:0.27 is enabled, both libgit2.so.28()(64bit) providers are filtered out by modular filtering (See: https://dnf.readthedocs.io/en/latest/modularity.html). 

Solutions:
1. In Fedora 30 the same problem was resolved by compat package "libgit2_0.28". The release of compat package "libgit2_0.28" into Fedora 31 resolves dependency issue. DNF team would prefer to use the same dirty solution for Fedora 31 rather than introducing other dirty hack. This solution also resolves the problem with gnome-software.

2. In dnf-plugin-system-upgrade we can add a conditional reset of libgit2 module when releasever == 31. This solution is applicable only for system-upgrade. Other upgrade tools will need to provide an alternative solution.

3. In dnf-plugin-system-upgrade we can add a conditional hint to run (dnf module reset libgit2) when releasever == 31. This solution is applicable only for system-upgrade. Other upgrade tools will need to provide an alternative solution.


The workarounds presented here must be use as a temporary solution to give us more time to resolve the primary cause of the issue. No other workarounds for Fedora 32!

Do I understand it correctly that the point 1. basically suggests that "libgit2" in F31 is renamed to "libgit2_0.28" in order to workaround the fact that modularity excludes packages based on name?

This might actually be the elegant hack. The problem is: Won't this bite again when upgrading to F32? Especially since "it must be a temporary workaround"?

(In reply to Miro Hrončok from comment #71)
> Jaroslav also proposed an alternate solution:
> 
> > What about alternative solution?
> > Modules axa, bat will be built not only with libgit2:0.28, but also with libgit2:0.26. This also resolves the issue.
> 
> Could you please elaborate?
> 
> 1. What does it mean to build the exa and bat modules against both
> libgit2:0.26 and libgit2:0.28?
> 2. How does this resolve the bug for exa/bat users?
> 3. How does this resolve the bug for Kat/GNOME Builder users?

To build exa package with libgit2.so.27 and libgit2.so.28 would also resolves the issue but in this case exa module will require module libgit2:0.27 or libgit2:0.28 (ship two contexts in the same version). But according to latest changes in Fedora 30/31 when exa requires only platform it would go in different direction that maintainers of exa decided - to not depend on other modules and to use non-modular libgit2. Anyway this solution is still possible.

You can't build exa against libgit 0.27.x or 0.26.x.

(In reply to Miro Hrončok from comment #73)
> Do I understand it correctly that the point 1. basically suggests that
> "libgit2" in F31 is renamed to "libgit2_0.28" in order to workaround the
> fact that modularity excludes packages based on name?


Modular filtering is based on name and provide search. Therefore compact package must not provide libgit2.

> 
> This might actually be the elegant hack. The problem is: Won't this bite
> again when upgrading to F32? Especially since "it must be a temporary
> workaround"?

The compact package is already presenet in Fedora 30 (but not in F31), therefore the problem in upgrade path is already there.

> Modular filtering is based on name and provide search. Therefore compact package must not provide libgit2.

So it means that the package cannot provide libgit2? that does not sound so elegant now.

> The compact package is already presenet in Fedora 30 (but not in F31), therefore the problem in upgrade path is already there.

I don't understand this statement. Yes, the problem is in the upgrade path is already here. If we workaround it by renaming libgit2, we need to keep it renamed forever, right?

Provides of libgit2 and libgit2_0.28 in Fedora 30:
sudo dnf repoquery libgit2_0.28 --provides
bundled(libxdiff)
libgit2.so.28
libgit2.so.28()(64bit)
libgit2_0.28 = 0.28.2-1.fc30
libgit2_0.28(x86-32) = 0.28.2-1.fc30
libgit2_0.28(x86-64) = 0.28.2-1.fc30

sudo dnf repoquery libgit2 --provides
bundled(libxdiff)
libgit2 = 0.27.8-1.module_f30+2959+693db98d
libgit2(x86-64) = 0.27.8-1.module_f30+2959+693db98d
libgit2.so.27()(64bit)


>> The compact package is already presenet in Fedora 30 (but not in F31), therefore the problem in upgrade path is already there.

>I don't understand this statement. Yes, the problem is in the upgrade path is already here. If we workaround it by renaming libgit2, we need to keep it renamed forever, right?

I would like to say that delivery of "libgit2_0.28" into F31 will not add any additional problem, because package "libgit2_0.28" already exists in F30. The same hack from F30 cannot provide any new problem in F31. But after removal "libgit2_0.28" from Fedora 32 we will get get same problem, therefore changes in modularity are required. DNF team cannot resolve the issue without additional information in metadata or changes in whole delivery workflow. I have to mention that DNF team cannot implement any solutions that are not acceptable by other distributions (like RHEL).

It is necessary to put the issue with other known issues on Modularity priority list. Can we count on Modularity team to work on it?

Jaroslav: would it be possible to do a workaround *in libdnf* like "if distro-syncing to F31, reset libgit2 module"? That should handle all known upgrade methods, as they all do distro-sync by default (at least dnf-plugin-system-upgrade, gnome-software and fedora-upgrade all do).

If we worry about people on F31 enabling a libgit2 module stream then running 'dnf distro-sync' (offhand I dunno why they would, but hey, people do weird stuff) we could add an ugly additional condition like "provider of system-release has .fc30 in its NEVR" or something...

...OK, "provider of system-release has .fc29 or .fc30 in its NEVR" :P

(In reply to Adam Williamson from comment #80)
> ...OK, "provider of system-release has .fc29 or .fc30 in its NEVR" :P

The `fedora-release` package actually doesn't have a .fcNN portion of the release tag because it's the source of it.

I'm sure we could find some other heuristic though. V of the NEVR == 29 or 30, maybe.

(In reply to Adam Williamson from comment #79)
> Jaroslav: would it be possible to do a workaround *in libdnf* like "if
> distro-syncing to F31, reset libgit2 module"? That should handle all known
> upgrade methods, as they all do distro-sync by default (at least
> dnf-plugin-system-upgrade, gnome-software and fedora-upgrade all do).

Auto-reset change in libdnf cannot be perform. Distrosync goal function have no information about relesever or about information that the transaction is going to move system into new releasever. Application or dnf-plugin that uses libdnf has the information and can used information.

Since we are very close to f31 release, let me toss out a crazy idea to be shot down: what if we had dnf-system-upgrade plugin set module_hotfixes=True ? That would solve this case, but would it break a bunch of others?

(In reply to Kevin Fenzi from comment #83)
> Since we are very close to f31 release, let me toss out a crazy idea to be
> shot down: what if we had dnf-system-upgrade plugin set module_hotfixes=True
> ? That would solve this case, but would it break a bunch of others?

The result of that would be that the upgrade would always try to install the highest NEVRA of any package in any of the available modules. That seems like it would go poorly.

Can we turn that option for libit2 only? Does it need to be set repo-wise?

The option module_hotfixes=True must be set per repository.

The option module_hotfixes=True cannot be used to resolve problem with libgit2. The command "dnf distrosync --releasever 31 --setopt=*.module_hotfixes=True" will always end up in disaster.

Can we have an extra repo with libgit2 only that has this option set?

Or is that too much hassle?

What about to return to proposed solutions:

1. provide a link from os-release file. This solution was implemented and released, and DNF team is going to support it in upstream. The content of the page is up to distribution. The solution was recognized as insufficient.

2. Other solutions:

(In reply to Jaroslav Mracek from comment #72)
> 
> Solutions:
> 1. In Fedora 30 the same problem was resolved by compat package
> "libgit2_0.28". The release of compat package "libgit2_0.28" into Fedora 31
> resolves dependency issue. DNF team would prefer to use the same dirty
> solution for Fedora 31 rather than introducing other dirty hack. This
> solution also resolves the problem with gnome-software.

What about this one? The delivery will be on the distribution.

> 
> 2. In dnf-plugin-system-upgrade we can add a conditional reset of libgit2
> module when releasever == 31. This solution is applicable only for
> system-upgrade. Other upgrade tools will need to provide an alternative
> solution.

DNF team can deliver it as a temporal downstream patch in Fedora 29/30.


> 3. In dnf-plugin-system-upgrade we can add a conditional hint to run (dnf
> module reset libgit2) when releasever == 31. This solution is applicable
> only for system-upgrade. Other upgrade tools will need to provide an
> alternative solution.

DNF team can deliver it as a temporal downstream patch in Fedora 29/30.

> 
> The workarounds presented here must be use as a temporary solution to give
> us more time to resolve the primary cause of the issue. No other workarounds
> for Fedora 32!

This statement is still valid.

(In reply to Jaroslav Mracek from comment #88)
> 2. Other solutions:
> 
> (In reply to Jaroslav Mracek from comment #72)
> > 
> > Solutions:
> > 1. In Fedora 30 the same problem was resolved by compat package
> > "libgit2_0.28". The release of compat package "libgit2_0.28" into Fedora 31
> > resolves dependency issue. DNF team would prefer to use the same dirty
> > solution for Fedora 31 rather than introducing other dirty hack. This
> > solution also resolves the problem with gnome-software.
> 
> What about this one? The delivery will be on the distribution.

I'm not particularly happy about this solution as it only shifts the problem to the next release.
User's won't be able to do `dnf install libgit2` in Fedora 31 if we do this.



> > 2. In dnf-plugin-system-upgrade we can add a conditional reset of libgit2
> > module when releasever == 31. This solution is applicable only for
> > system-upgrade. Other upgrade tools will need to provide an alternative
> > solution.
> 
> DNF team can deliver it as a temporal downstream patch in Fedora 29/30.

I like this solution and I've always did.



> > 3. In dnf-plugin-system-upgrade we can add a conditional hint to run (dnf
> > module reset libgit2) when releasever == 31. This solution is applicable
> > only for system-upgrade. Other upgrade tools will need to provide an
> > alternative solution.
> 
> DNF team can deliver it as a temporal downstream patch in Fedora 29/30.

This is the second best thing for dnf system-upgrade. However I'm, not sure how suitable it is for gnome-software (probably isn't).

> Can we have an extra repo with libgit2 only that has this option set?

This will means additional work for relengs. Every solution means work for at least two team.

I, personally, found the workaround in DNF in Gnome Software most straightforward and with least impact on surrounding ecosystem.

JMracek is willing to do the work in DNF. Let's handle Gnome Software separately. I filed:
  https://bugzilla.redhat.com/show_bug.cgi?id=1762751

> 2. Other solutions:
> 
> (In reply to Jaroslav Mracek from comment #72)
> > 
> > Solutions:
> > 1. In Fedora 30 the same problem was resolved by compat package
> > "libgit2_0.28". The release of compat package "libgit2_0.28" into Fedora 31
> > resolves dependency issue. DNF team would prefer to use the same dirty
> > solution for Fedora 31 rather than introducing other dirty hack. This
> > solution also resolves the problem with gnome-software.
> 
> What about this one? The delivery will be on the distribution.

What about future? Will if be fixed in F32 timeline so we can drop such package?

I create a patch that resets libgit2 when releasever == 31 - https://github.com/rpm-software-management/dnf-plugins-extras/pull/166.

FEDORA-2019-7656a4dd09 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-7656a4dd09

FEDORA-2019-e8db3bef68 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-e8db3bef68

$ dnf system-upgrade download --release=31
...
Resetting modules:
 libgit2

As the fix here goes to F29 and F30 and does not require change in the F31 compose itself, changing to AcceptedPreviousReleaseBlocker. The effect of this is that we do not block the F31 composes on this bug, but a fix must be *stable* in the F29 and F30 repos on or before F31 release day.

dnf-plugins-extras-4.0.7-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e8db3bef68

dnf-plugins-extras-4.0.7-2.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-7656a4dd09

dnf-plugins-extras-4.0.7-2.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

Re-opening as we still need to track the F29 update.

dnf-plugins-extras-4.0.7-2.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

Clearing CommonBugs as we fixed this ahead of Final.

I've opened bz1767351 as a Fedora 32 followup. Both workarounds are explicitly only done if the targeted release is Fedora 31, hence Fedora 32 is still broken.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days