Also https://github.com/fedora-modularity/libmodulemd/blob/master/README.md#working-with-repodata-dnf-use-case may prove useful.

Module Build Service (MBS) builds fail on non-RHEL7 systems because MBS uses DNF to find the list of NEVRAs in a repository, and this fails because MBS uses libmodulemd v2 and libdnf uses libmodulemd v1. This blocks local builds from working correctly since the majority of users use Fedora for those.

Here is a reproducer Python script that demonstrates the issue:
```
import logging

import dnf
import gi
# If this is 1.0, this script works just fine
gi.require_version('Modulemd', '2.0')
from gi.repository import Modulemd

logging.getLogger().setLevel(logging.DEBUG)


repo_url = 'https://kojipkgs.fedoraproject.org/repos/f30-build/latest/$arch/'
base = dnf.Base()
dnf_conf = base.conf
dnf_conf.metadata_expire = 0
dnf_conf.cachedir = '/tmp/dnf-reproducer'
base.reset(repos=True, goal=True, sack=True)
repo_name = 'f30_x86_64'
repo_arch_url = 'https://kojipkgs.fedoraproject.org/repos/f30-build/latest/x86_64/'
base.repos.add_new_repo(repo_name, dnf_conf, baseurl=[repo_arch_url])
base.repos[repo_name].load()
# This stays stuck with the error
# `Module yaml error: Document type was unspecified or unknown`
# when `gi.require_version('Modulemd', '2.0')` is set
base.fill_sack(load_system_repo=False)
print(len(base.sack.query().available()))
```

We investigated the code of libmodulemd-2 and we found significant differences that will brake our API. Or probably we are looking at it by incorrect way therefore I would like to ask for help with porting. Please could anyone familiar with libmodulemd-2 API help us?

(In reply to Jaroslav Mracek from comment #10)
> We investigated the code of libmodulemd-2 and we found significant
> differences that will brake our API. Or probably we are looking at it by
> incorrect way therefore I would like to ask for help with porting. Please
> could anyone familiar with libmodulemd-2 API help us?

You are correct, it is absolutely an ABI break (because the API and ABI of v1 is terrible and difficult to maintain and even more difficult to *use*)

I'd be very happy to help with any porting efforts. I tried to look into it myself a few months ago, but I don't have a sufficient understanding of the way it works currently to get anywhere. It would be best if I could sit down for a few hours with one of the DNF developers and work through it.

I know this is a RHEL bug, but from the point of view of the maintainer of the DNF package manager in Mageia, OpenMandriva, openSUSE, and now ROSA, I'd *really* like to see this done sooner rather than later. It's a rather annoying complication to ship both versions and the bugs resulting from differing behaviors in module processing due to the different libraries is rather insane.

Yes, I am actively working on it but its going to take some time.

Ales, I've added:

* https://fedora-modularity.github.io/libmodulemd/latest/modulemd-2.0-Modulemd.ModuleIndex.html#modulemd-module-index-search-streams
* https://fedora-modularity.github.io/libmodulemd/latest/modulemd-2.0-Modulemd.ModuleIndex.html#modulemd-module-index-search-streams-by-nsvca-glob
* https://fedora-modularity.github.io/libmodulemd/latest/modulemd-2.0-Modulemd.Module.html#modulemd-module-search-streams
* https://fedora-modularity.github.io/libmodulemd/latest/modulemd-2.0-Modulemd.Module.html#modulemd-module-search-streams-by-nsvca-glob

to libmodulemd, targeted for the 2.9.0 release. This will allow you to query libmodulemd for streams matching patterns supported by fnmatch(3). Can you let me know if there are any other API calls missing from libmodulemd that you need?

Yes of course, thank you.
Sorry if I have been unresponsive on GitHub lately, but I am just slowly trying to get it to work and pass our tests. I will surely let you know if there's anything needed.

I have created a PR: https://github.com/rpm-software-management/libdnf/pull/894

I didn't use any of the new functions yet, I am not sure how jmracek wanted to use them, I will ask about it.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (yum bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:4510