On Mon, Feb 11, 2019 at 3:30 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Sun, Feb 10, 2019 at 9:22 PM Dridi Boukelmoune > <dridi.boukelmoune@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
