Hello, I just wanted to give you an update from my last discussions on #fedora-modularity and other places. # Problems definition * Default modules can't have conflicting dependenices * Changing dependencies in a stream is not supported # Why does libgit2 has to be a module? libgit2 is not just one package. It is an ecosystem. Right now libgit2 module provides libgit2 itself and python bindings. While we can obviously provide libgit2_0.26, libgit2_0.27 and such, this does not help us with python packages. Nobody in sane mind will rename them and make them conflict (because they are not parallel-installable). I wanted to also add ruby bindings to a module, but I never got time to actually do it. # What about dependencies change? Let's not lock ourselves into libgit2 story, just take an abstract names. Module foo:rolling depends on bar:1. Name of stream "rolling" means to serve purpose of "user-focused content meant for general use". That means, if foo's upstream decided to update their bar dependency to a new version, foo:rolling maintainer would just switch dependency to bar:2. However, with modularity once you enable stream (and "bar:1" gets enabled implicitly), you stay on it forever. This means that maintainer of "foo" just can't change dependencies ever. This is just bad. I think solution here is to teach DNF about implicitly enabled modules and switch streams for them when needed. Or even add flag "--i-know-what-i-do" for the time being. From what I understand, this has been done so that systems do not break ever… However, with right RPM dependencies, I think this should not be a problem. And after all, RHEL can be different from Fedora. Right now DNF resolves dependencies of modules separately from RPM ones (which is yet another thing worries me[0]). If we teach it to do it at once, we can be sure that whatever is installed locally by RPM, will not have broken dependencies so it will prevent switching stream. # Why should defaults conflict? Let's think what defaults mean and why they even exist. People used to do "dnf install foo" and get their package. With modularity, they would need to explicitly enable some module. Here we come to the defaults. Packages from default streams are available for installation without explicit enabling of modules. Installing the actual package will trigger enablement of a module stream (so that it does not get upgraded to an incompatible version). In Fedora we try to make as much as possible to be parallel-installable. However, this is not always possible. Conflicts happen everywhere. If foo and bar can't be installed in parallel, we do not just abort when not installing both of them at the same time. You can install foo separately from bar. This is unfortunate, but that's what it is. Why modules have to be different? Default modules are there to make packages available for selection. When user will try to install them and there is a conflict, only then DNF should show an error. Not in any other cases. # What should we do now with modularity and libgit? I can change libgit2 module to provide static subpackages and teach Rust applications to link statically so we won't have these dependencies. But this is temporary workaround because we don't have any automation for rebuilding modules or rpms on a dependency change. What I think should happen is DNF team to provide an ETA to fix issues above and depending on that we can see whether we should take this path or just throw away modularity and focus on other solutions which are not that invasive. [0] https://bugzilla.redhat.com/show_bug.cgi?id=1677746 On Thu, Jun 13, 2019 at 9:22 PM Adam Samalik <asamalik@xxxxxxxxxx> wrote: > > So, I'd like to discuss the libgit issue [1] [2] we're experiencing. With a help of a few people, I've put together this post to get us on common ground: https://communityblog.fedoraproject.org/modularity-vs-libgit/ > > There are few ideas about solving the issue right now. But we might be able to think about better ways to deal with similar issues long-term. Let's do this! > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1717117 > [2] https://pagure.io/fesco/issue/2146#comment-575852 > -- > > Adam Šamalík > --------------------------- > Senior Software Engineer > Red Hat > _______________________________________________ > 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
