On Fri, Sep 11, 2020 at 12:32 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > This exchange summarizes the situation nicely. > > Modularity can be considered an over-complicated hyped-through-the-roof > bundling mechanism. > > For a long time Fedora has very strongly discouraged bundling in the sense of > subsumming one package into another to have a custom build of a dependency. > > The disapproval of bundling is not because it doesn't work: it does, and in > fact with some crappy libraries it's the least bad solution. The disapproval > is motivated by the fact that bundling doesn't scale and that it subtracts from > the ecosystem. Instead of us all cooperating and each bugfix helping all > users of a given dependency, a maintainer of a bundled library is only helping > themselves and their package. > > Bundling is not inherently bad: currently the policy even allows it as > a workaround if using the system-wide package is not feasible. It is a > pragmatic choice to allow it as a last resort. But the effect of bundling > on other packages must be minimized any conflicts or confusion with the > system version avoided. > > With Modularity, we threw this accumulated wisdom away. > In two ways: by encouraging private^Wbuild-only dependencies and by > letting bundled^Wmodularized rpms shadow normal rpms. > > For Maven packaging the appeal of Modularity is clearly the privatization of > the dependency tree, which obviously undercuts the ecosystem of packages. > > The Java ecosystem collapsed so quickly because it was already weak > — hundreds of packages on the shoulders of one person. But even in a stronger > ecosystem, with enough packages modularized, the packaging ecosystem of > mutual cooperation would collapse. > > For some other modules, the appeal is the overriding of package deps, which > means that the modular rpms don't have to worry about getting it deps precisely > declared, at the cost of breaking the deps declared in other packages. > > If there wasn't Modularity and instead Maven would bundle it's deps into > one huge srpm, the effect on the ecosystem would be the same. As with > bundling, Modularization gives short-term relief at a very high long-term > cost. We should avoid modularization like we avoid bundling. You summarized it really well, thanks Zbyszek. To me bundling is, and always was, an important design feature of modularity. There are other important aspects of it, but I dare to say that from my PoV its form of bundling is the most important feature. I wanted to expand on your story, present my version of the same story. For a long time we (Java maintenance team at Red Hat) were maintaining Fedora packages without any form of bundling because it was considered harmful and was not allowed in any way, not without explicit exception. Over time the number of contributors to Java packaging (number of active Java SIG members) was decreasing, most of Java maintainers were gone, or "unresponsive". Making changes to our packages, like improving packaging automation, required testing and possibly adjusting thousands of others' packages, most of which were largely unmaintained. Unresponsive maintainer processes would not work as it would require us to take maintenance of orphaned packages, which we could not afford. In the meantime our Java maintenance team was shrunk from 4 people down to just one person, me. I had to severely limit the time I spent on Fedora due to other commitments - I had to spend more time on RHEL work and other side projects, like Koschei, that I was responsible for. I could not afford to spend my free after-work time on Fedora due to personal reasons (I got married, started building a house etc.) Combined with the collapse of Java SIG, the situation was difficult. Then a new, sophisticated way of bundling, called modularization, was designed and came to my help. This way of bundling was no only considered not harmful, but also approved and even made as a Fedora objective. Since it solved the biggest issues I had with packaging, I became a very eager early adopter and quickly built everything as modules. I was still maintaining non-modular packages, but I hoped that one day non-modular packages would be completely replaced by modules. When modules were added to Fedora proper, I made them default streams and waited for a solution like Ursa-Major that would allow me to retire ursine packages, replacing them with modular packages. RHEL enabled Ursa-Major. My javapackages-tools module was the first ones to make use of it in RHEL and we succeeded to retire all ursine packages in RHEL. When Fedora finally rejected Ursa-Major, I was very frustrated as I perceived it as begin of collapse of modularity, the great feature that promised to solve the problems I had with packaging. I could not easily move back to ursine packages and I was already committed to maintaining modules in RHEL, so I decided to live with Fedora decision and orphan almost all of my ursine packages. Since then I've been mostly working in MBI project, which has become a new upstream for Fedora and RHEL modules. In MBI I made great progress at improving the packages and reducing their number by more than half - I didn't have to worry about breaking users or others' packages, and I was not limited by constraints of Fedora infrastructure. In the meantime modularity was mostly withdrawn from Fedora - default streams and then module-only packages were disallowed, which to me means total failure of modularity as a primary way of delivering software to users. Now I can't move on with modules as I don't have any chance against anti-modularity trends. I can't convert my modular packages to ursine packages as this is not allowed by the policy, and would not be appreciated by current owners of ursine packages. I can't drop my packages and move back to co-maintaining ursine packages as it would mean losing 2 years of my work and the features I developed. The best I can do is to wait and see what happens, while working on the packages outside of Fedora, as part of the upstream MBI project. >From a time perspective I do consider modularizing my packages as a mistake. But I don't see any sensible way of going back. -- Mikolaj _______________________________________________ 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
