V Tue, Jun 13, 2023 at 03:20:06PM -0400, Christopher napsal(a): > (First the negative... don't worry, it's not all negative) > I wonder why we need this at all. I believe that modularity has failed > to gain a foothold in Fedora, just like scl before it, because Fedora > just doesn't need this. One of the best things about Fedora is the > dependency-convergence and curated nature of all the packaged > versions, so that everything works out of the box. The use cases for > alternative versions are edge cases that the vast majority of users do > not need or care about. And the ones that most users do care about > (making sure their application works) are usually satisfied with > compat packaging, when needed. > > So much (over-?)engineering has gone into such niche use cases, and > Fedora is arguably no better off for all that effort. Nowadays, it's > so easy to spin up a VM or container using older versions of things, > if you need them, or you can use snaps or flatpaks, or > language-specific version management tools like mvn or rvm, for the > developer use cases. What is the real benefit to Fedora to continue to > push down the path of alternative, mutually-exclusive streams that > affect the entire system? My experience struggling with modularity as > a casual packager, and as a user, has left a bad taste in my mouth for > any similar attempts, and I'm highly skeptical of the need of such a > thing (and bracing for the impact when it all comes crashing down on > my favorite OS due to unintended consequences). > I agree that for Fedora it's a niche problem and any attempt to introduce alternative versions never flew long there. My explanation for it is that what Fedora offers and what Fedora users want is a self-inforced relation. If Fedora choose a short release cycle with single-version, well-integrated code base, then naturally any attempt to bring alternative versions which partion the code is frown. There are different distributions with a different life cycle, e.g. rolling release, that incorporates incompatible versions as an inevitable phenomenon. Those distributions of course have a different vision and different user as well as packager base. This is not a critique of Fedora. It only illustrates that different distributions have different priorities. You can take my proposal as a mental exercise to explore what is possible and what isn't with the current state of packaging in Fedora. I'm not going to hide that the proposal more targets to long-lifecycle derivates of Fedora and I wanted to get a broader audience, especially from Fedora as an upstream. > (Now the positive) > That said, I like the simplicity of your approach, using metapackages > and native RPM tooling to handle the situation. However niche the use > case is, having such a simple approach means that it's merely a matter > of documenting some guidelines for packagers to follow if they have > need of that situation. I still think that the need for that will be > rare, and wonder how many of these kinds of metapackages would > actually get created in Fedora. I suspect that it would be very few. > But the important bit is that if they do get created, they are > unlikely to affect me unless I want to use them. This is very > different from modularity, which seemed to have a downstream impact on > everybody, especially when you were forced to use modularity if your > dependencies were... which I think was enough to oust a lot of casual > packagers, because they had to understand a whole new dimension of > packaging guidelines and tooling. Your approach requires none of that. > > The one downside to your approach, that I think was an early selling > point of modularity, is that yours kind of requires that the > alternative streams are built for every Fedora version. I think > modularity marketed itself as being able to have a module whose > version lifetimes were longer than OS release cycles (which could > reduce packager workload for streams that were slow-moving and didn't > change across Fedora releases). I don't know how much that actually > happened in practice, though, so I don't know if anybody will care > about that difference in your approach. Thanks for the review. Modularity indeed helped to maintain a single source across all Fedora releases. However, behind the scene it spawned separate builds and updates for each Fedora release. (That's something that current JDK proposal tackles <https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs>.) Very contrary, one had to rebuild a module for each new release. Otherwise, the module disapeared from Rawhide. My proposal does not bring this feature. I think packagers can leverage packages.cfg file in dist-git repositories to configure multiple builds with a single "fedpkg build" command (as it was used in EPEL8 for EPEL8-next builds). -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
