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