On Wed, Oct 5, 2022 at 6:19 PM aleksander.baranowski via CentOS-devel < centos-devel at centos.org> wrote: > On 10/5/22 23:34, Nico Kadel-Garcia wrote: > > Is anyone at all finding modularity to be genuinely helpful? Because > > EPEL has abandoned modularity, compiling or integrating local versions > > of packages or EPEL related packages has been a real hindrance for > > those of us who publish new python RPMs or backport them from EPEL. > > Given EPEL's abandonment, it does not seem to have been worth the > > resulting instability. No one likes to build modules and maintain packages that uses them xD. I > could write a huge rant about it, but I believe that **You are asking > the wrong people.** > > Users, they experience, opinions and actual data about usage would be > much more helpful. I believe that RH has this kind of data with proper > analyses. > I use Fedora as well as various EL distros in my day-to-day, and one thing I've noticed from the start is that Fedora modularity doesn't tend to get in my way, while RHEL and derivatives, modularity gets in my way every day. This may depend upon people's expectations and workflows. Let's pick qemu-kvm as one example. In Fedora, it's part of regular base + updates. It "just works", and doesn't seem to interfere. But, in RHEL 8, somebody decided to take it further, and proactively put it in "virt" and "virt-devel". Then, they identified any libraries that they thought were "virt" related, and put them in there, splitting them up, forever to create confusion. With the RHE-V / CentOS Advanced Virtualization, the modularity system had to be disabled to allow this to work because not only did nobody understand it, but the number of dependencies that had to be embedded to do it "properly" was a huge amount of work. It wasn't good enough to just provide a better "qemu-kvm" - you had to provide the entire set of libraries that it depended upon as well. This seems to have settled with the merged of CentOS Advanced Virtualization into CentOS 8 Stream, and then release in RHEL 8.6, but that's a very long time to run with effectively a package conflict in your environment. A package conflict which modularity was designed to *solve*, not *create*. Or, let's pick Docker as another example. Docker CE / EE didn't work on RHEL 8 without bypassing modularity, due to the same problem as above. Dependencies were not embedded with Docker CE RPM upstream, but why should they have to additional produce containerd.io and others, just to contribute? Much of this conflict also seemed to do with podman and others, that selecting the module enabled that would be in direct conflict, but if you didn't enable the module, you were missing dependency packages. This seems to have all settled - I think possible because Docker CE RPM is basically self-container written in Go, and once they got the dependency list down, and the work-arounds documented in code, it is working again. But, this is another case where modularity was designed to solve this problem, not create it. I think modularity is highly misunderstood. Maybe because it is confusing. Modularity is not a very good way of separating your OS into logical components like "virt". We already have Yum groups to do that. The benefit of modularity (at least to me), if there is still one after the abuse has left people scarred and angry, is the ability to publish conflicting releases of a component side-by-side in the Yum repository, and allow the user to resolve the conflict by identifying which one they wish to expose. In the case of qemu-kvm, it might work if it embedded fewer dependencies, and if they actually published different versions of Qemu side-by-side, and tested it, and resolved the overhead by feeling it for themselves. But, by proactively publishing a "virt" and putting everything "virt" into it, they created something that basically "can't" work without huge amounts of effort and confusion, with most people just bypassing modularity rather than trying to deal with it. But also - I'm not sure that anybody asked for qemu-kvm to stay old. Why is qemu-1.5.3 normal in RHEL 7? Why was qemu-2.12 normal in RHEL 8 original release? For Docker - at least on the surface, it seems like podman and others was an attempt to distinctly depart from Docker upstream releases, and provide an entirely new thing, with a clear effort of making it easier to use podman, and hard to use Docker. I suppose it could have been a zealous accident, but I think the people involved are far too smart to be making such accidents. I think this was all against the backdrop of the policies around package life cycle, mixed with politics around making RHEL unique value-add compared to others, and this spilled into the complex modularity system, and resulted in something which was worse, than not doing modularity at all. Bad for RHEL. Bad for people trying to create their own value-add on top of RHEL. But, that's how a lot of these things go - and this certainly isn't the biggest such move or consequence in recent times. There are other packages such as Python, that are impractical to use the module system on, and the older model of having packages installed side-by-side with their own names, and alternatives in front, still works great for many of these. Beyond pointing out things that might be obvious - I think my real point, is that I don't feel harmed by modularity in Fedora. I've tried to explain why I think that is. I think Fedora used it in places that it more often looks like value, and less often creates conflicts. Or, maybe my workflow is just lucky. I think modularity being bad, is like calling a hammer bad. A hammer isn't bad at driving nails. A hammer is definitely bad at many other things. :-) -- Mark Mielke <mark.mielke at gmail.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20221009/76c9da37/attachment-0003.html>