On Tue, Jun 13, 2023 at 12:33 PM Petr Pisar <ppisar@xxxxxxxxxx> wrote: > > Hello, > > as it seems that module build infrastructure isn't getting any better, as > modular YUM repositories are going to be deconfigured > <https://fedoraproject.org/wiki/Changes/No_default_fedora-repos-modular>, > there is a time to look at different ways how to package alternative content. > > There are few aproaches, like compat packages, or full namespacing (Python). > Yet modularity had some unique features, especially retaining nonmangled > package names and other RPM dependencies. > > I spent some time thinking how to approximate the nice features with current > state of RPM, Koji, and DNF and come up with this approach > <https://ppisar.fedorapeople.org/postmodular/>. The linked approach achieves > it at the expense of dedicated build targets and an inability to introduce > completely new modules (as opposite to new streams of existing modules) after > releasing an installation media. > > Comments are welcome. > > -- Petr (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). (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. _______________________________________________ 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
