On Sun, Feb 10, 2019 at 9:22 PM Dridi Boukelmoune <dridi.boukelmo...@gmail.com> wrote: > > > I don't read repodata manually, libsolv does it for me. Using libdnf and/or > > libmodulemd is not something what (for example) OBS would do. They rely on > > libsolv for all dependency solving operations. And unless it will support > > modularity (which depends heavily on DNF people's ability to speak to > > upstream), nothing will improve. > > I don't know how things are currently done, but shouldn't modularity > build on top instead of being bolted in? >
"Build on top" does not make sense, because each of the aspects are crossing into each other in order to provide a useful solution. > I assume libsolv can already deal with multiple repodata since yum/dnf > support having multiple repositories. Shouldn't modules simply provide > repodata and have the "modularity" plugin figure which repodata to > fetch depending on the selected streams? That wouldn't require any > change in libsolv. > This is actually how it works now, but causes all kinds of problems, even in DNF itself. If you try to get debugsolver data for debugging issues with DNF, it makes absolutely no sense because the solver doesn't know anything about RH modularity. This means that solutions are slower and suboptimal. It also makes development on improving the technology very hard. It also increases the memory requirements because everything has to be held in memory while a second solver runs on the data to apply various filters. And the solution "logic" for modules is very similar to how yum did solutions for RPMs, so it's quite slow and prone to issues. > Disclaimer, I don't know any better but if modules are simply > parallel-available RPMs, it shouldn't be bothering libsolv (except > maybe to enforce a stream downgrade). > Modules are effectively mutually conflicting collections of RPMs, operating like stacked/nested repos with the properties of composition groups. They also contain all kinds of extra information which is used to determine availability, usability, and other things. If they worked the way you thought they did, we wouldn't be having these issues. :( -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
