Hello Adam and everyone else, I want to point out that there are 2 issues and not just one as described in the article.
1) Default streams can't conflict 2) Switching dependencies on a module does not work Both of the issues are solvable and should be handled by DNF, however they are not. And I could not get any ETA on fixing that. So the article talks about second issue. I'll comment on it first and then I'll talk more about first issue. # One stream with compatibility packages This is not entirely doable. While library itself can be installed in parallel, the devel package can not. So this would mean I would either have to ship only one devel package which would not make sense or do terrible hacks to install them in parallel (like mangling /usr/include directory, pkg-config and such) and it won't work correctly. And after all, what is the advantage of modularity in this case? I can do the same in traditional Fedora. # New streams of silver and bat So we will have then silver:rolling, silver:rolling-new, silver:rolling-very-new and such? Note that I simply can't support old streams. They would need to go EOL as soon as I create new one. And we decided not to do. Streams must be supported by people within active Fedora release. So this is not solution to a problem at all. # Bundle libgit into the silver and bat modules Yes, I can link libgit2 statically everywhere. I don't even have to include that package, I just have to ship static version of libgit2. The problem here is that since in Fedora we don't have any automation for rebuilding modules / packages, every time something changes in libgit2, I would have manually go, check what to rebuild and do that rebuilds. # Potential solutions for the future So we don't even look at solution named "Just Fix DNF"? Now to the problem which was not described in the article.. In order to describe, I'll start in short points what was before and what has changed. * Fedora 29 and 30 have non-modular libgit2-0.27 * Fedora 31 has had non-modular libgit2-0.27 as well, but last or this week has upgraded to libgit2-0.28 * All Fedora versions ship 0.26, 0.27 and 0.28 streams of libgit2 as a modules * All Fedora versions have default stream set to match non-modular version (due to not having Ursa Prime ready) * silver, bat, exa and more modules have default stream and used to depend on libgit2:0.27 and have been rebuilt (most of them) to depend on libgit2:0.28 Here I should introduce what "default stream" means for users. Users should be able to just do "dnf install silver" and that should enable default stream of module which provides package "silver". That means, until you do installation, they can conflict. It might be not very nice for users, but this is valid. So if we have default tokei:rolling which depends on libgit2:0.27 and default libgit2:0.28, you should be able to install either tokei which would install libgit2:0.27 or if you do "dnf install libgit2", it would install 0.28 and you won't be able to install tokei. What happens today is DNF just always complains and does not allow you to install an operating system. So simply untagging new builds of modules won't help, because then modules will start depending back on libgit2:0.27 while rawhide has already default for libgit2:0.28. Neither you can change a default back to 0.27 because non-modular libgit2 has been upgraded and all packages were rebuilt. There are 2 solutions for this problem (not including fix of DNF): 1) Unset all defaults for Rust applications. This will solve problem of not being to install an OS, but it won't solve issue with upgrades. 2) Untag new builds for Fedora 29 and 30, stop shipping updates for Rust applications there and let them rot. For rawhide, I can rebuild last few modules to start depending on libgit2:0.28, so rawhide will be back on track. First option is just horrible. Second one is okay-ish, but before this way would be chosen I want to hear what is the ETA for fixing these DNF bugs. I do not want Rust applications just rot in stable releases. On Thu, Jun 13, 2019 at 9:22 PM Adam Samalik <asama...@redhat.com> 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@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 _______________________________________________ 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
