On Fri, Nov 15, 2019 at 3:31 PM Joe Orton <jorton@xxxxxxxxxx> wrote: > > On Fri, Nov 15, 2019 at 12:44:52PM +0100, Miro Hroncok wrote: > > Where is the end-user benefit with the modular default stream? I don't see > > it either, sorry. Let me offer a second opinion (coming from some first-hand experience) here: > It's not clear to me how those examples are related to my argument, > which I could summarize as: > > a) multiple module streams have a benefit to users, and I think this is a valid point, and it's one of the biggest benefits of Modularity. But default streams are orthogonal to this. > b) default streams have a benefit to package owners. This, however, is not true for fedora in my experience (it may be true for RHEL, though). See my explanation below. > > > This comes at a high cost to package owners if we have to keep > > > non-modular packages - we have to maintain, build, and test X streams > > > plus Y non-modular release branch builds for each component, rather than > > > just X streams. > > > > Yes. This is the benefit of the default modular stream for the modular > > maintainers. I have never questioned it. I don't even think that it's a (big) benefit for modular maintainers. > OK great, though it is a bit surprising to hear in a thread which you > started explicitly to question the benefits of default modular streams. Ok, let's say you're maintaining default streams for 3-4 fedora branches instead of 3-4 fedora branches "separately". I disagree that this makes maintenance easier for the package owner *in general*. Since there are inherent differences between the fedora "base systems" in the different branches, one of the following things must be true: - Either there will have to be a different default stream for some fedora releases (making you maintain multiple branches anyway), or - you will need %if%else%endif spaghetti in your .spec files to support all branches of fedora you target at once. Is this "easier" than using the clean separation provided by git branches for non-modular packages ? Probably not. (But hey, some maintainers do like their %if%else%endif spaghetti because they want to git merge stuff from rawhide downwards. I don't.) > > In my opinion (and that is my very subjective opinion, but based on > > experience) the cost of that difference is otherwise paid by everybody else. > > > > The group of everybody else is very much bigger than the group of modular > > maintainers. Hence, I'd approve such trade off. I agree. This is very much in line with the "be excellent to each other" maxim. Making my own work easier at the expense of making things worse for everybody else who depends on my stuff is most definitely not "excellent". > So it's clear to me that you see that packagers chosing default streams > over non-modular packages impose external costs on the rest of the > distro (packagers and/or users?) somehow. This thread was supposed to > focus on benefits, and these vague claims about costs and trade-offs > seem speculative, but maybe you could expand on that a bit? I can provide one example (or two). Probably the worst "offender" here is the "maven" module. The original maintainers of most Java packages decided to drop all their "non-modular" packages and leave them to bitrot (side note: the bitrot started happening in 2017, but it got much worse in 2019, when packages were starting to get retired after 6 weeks of being orphaned). This situation also forced eclipse into becoming a module, because many of their dependencies were now effectively unmaintained or broken. It was also the explicit reason for the founding of the Stewardship SIG - to make sure at least basic Java packaging stuff is still working (otherwise, LibreOffice would now be broken in fedora 31+). Also, currently, the "maven:3.5" branch is the default maven stream for fedora. This means that everybody who "dnf install(s) maven" will get maven 3.5, despite maven 3.6.1 being available as a non-modular package in rawhide now. On the other hand, this was a major reason why Ursa Whatever wasn't enabled for all default streams, because maven from the 3.5 branch isn't able to build RPM packages. Yikes. If I understand correctly, mizdebsk is working on making maven from the modular branches be able to install in parallel with non-modular maven packages, which would solve at least this particular issue with maven. Still, I don't understand why modular branches for Java packages are even necessary, and why it was necessary to force eclipse maintainers to modularize eclipse as well. Sigh. At least for the forseeable future, non-modular Java packages will stay maintained, even if the Java SIG is basically nonexistent now. Another issue is that the modular Java packages are now getting built with OpenJDK 11, while the non-modular default is still OpenJDK 8, and nobody is left to drive an OpenJDK 8 → 11 transition in fedora forward. We're basically the only holdout on Java 8 still, with even debian stable (!) defaulting to OpenJDK 11 now. This will probably lead to all kinds of fun incompatiblities between modular (Java 11) and non-modular (Java 8) packages. And I've not even mentioned the myriad of other, slightly incompatible changes between modular and non-modular Java packages ... *SIGH* I hope this can give you some examples why actually, moving things to default streams is making things worse for almost everybody, including both packagers (of dependent packages), and users (who may get either outdated, broken, or incompatible packages). Now, I know that the "maven:3.5" and "ant:foo?" streams would not get accepted as default streams today, because they conflict with non-modular packages. But they still are defaults, and it's causing problems. Fabio > Perhaps this stuff is obvious to others already. In RHEL8 while we have > certainly hit various problems with modularity at least I don't recall > my teams hitting major issues with default streams being available for > non-modular packages. Maybe the dogtag-pki team can offer some opinions here? I know that they've had to deal with this on both RHEL and fedora. Fabio > Regards, Joe > _______________________________________________ > 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 _______________________________________________ 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
