On Mon, Feb 11, 2019 at 3:30 AM Neal Gompa <ngomp...@gmail.com> wrote: > > 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.
Yes but dnf provides an API and you can build features on top of it. For example version locks (that could help enforce a stream) protected packages (that could intercept attempts to remove a module outside TheRightWay(tm)) etc. I don't see why we should mess with the RPM dependency solver in an intrusive way and not feed it the result of "module" dependency solving. In other words, I don't understand why we need to special case modules in build roots. > > 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. I never had the bandwidth to follow modularity in the making, so I'm still very clueless about the implementation. But the fact that I have a fairly good understanding of the "installation process" (in a broad sense) in Fedora and can't grok modularity feels like something was wrong in the base design. > > 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. :( To me it feels like Red Hat had an agenda and a time table, and the whole thing was rushed for the sake of RHEL 8's time to market. When people blame Red Hat of using Fedora as a test bed, I can only sympathize because it really feels like that. I don't mind, but when the answer is no, Fedora is an independent community project, I also don't buy it. I really think that the current design shortcomings come from the lack of time allocated to it, or maybe the lack of exposure. Again I don't have the bandwidth to follow major changes in Fedora, for example it took me forever to even start dropping the python2 packages I happen to maintain. Dridi _______________________________________________ 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
