> I'm with you in the sense that I too fail to see practical benefits of > modules so far. But e.g. the java-sig says it makes their life easier, > and it is their choice. The decision was made to proceed with > modularity in Fedora. Once that decision was made, we cannot forbid > packagers from making use of the new functionality. This further step > is only a natural consequence.
Besides not seeing benefits of modules, while I do understand the rationale it's also something I disagree with. I feel like modules go against the First principle, I get a sense of bundling there too. But if anything, it feels like we are going full circle again with Snaps and Flatpaks and being pushed into an "innovation" corner by Canonical's agenda just because they have enough momentum to make everyone believe there is something wrong with the current packaging model. Snaps made sense for Ubuntu phones to deliver arbitrary apps from a store, not something suited to a general-purpose OS like Fedora. Shipping Snap and Flatpak as packages, sure, but shipping Snaps or Flatpaks, I don't see the point besides throwing away the progress made since the years of the so called RPM hell. We're already seeing examples of "portable packages" not keeping up with upstream releases (the last I heard of was nextcloud) and either a package is stable because upstream projects know how not to break carelessly or they really need to live at head because $REASONS (web browsers, probably things like nextcloud, etc). We have the same problem with lagging updates for "traditional" packaging so I have yet to be convinced that modules, Snaps or Flatpaks will solve that. I'm not knowledgeable enough about how Fedora manages parallel installation of streams but at the end of the day if I run "node" from the command line only one executable will be picked up from my $PATH. How can I run multiple streams then? Are the packages tweaked so that I run node8 or node10? How is that different from compat packages? I guess the answer is the bundling of dependencies inside both modules, I don't know for sure, I do not wish to dig further because I only have so much time to dedicate to Fedora. I'd rather go for OmniOS-like packaging guidelines for parallel installations and module switching basically be an update-alternatives to put things on the default $PATH or let users tweak their $*PATH when they need to target a given stream. (And yes, I know it doesn't sound friendly to non-tech-savvy users but how often do they need parallel installations of GUI apps?) I just hope modularity won't break mock as I know it. My $DAYJOB kindly allows me to work on Fedora and that makes me very productive when I target RHEL, otherwise I need to spin up VMs whenever I need to work on other platforms packaging (mostly because we ship apt-rpm as /usr/bin/apt). I happen to work on both an upstream of Fedora and many other systems, and on Fedora, so I know how hard it is to DoTheRightThing(tm) on both sides of the fence. To me this sounds like something that should be built on top of mock and made transparently available via fedpkg but I have neither the will nor the resources to look further than what I superficially read on the devel list (and when I rarely manage to catch up with all important threads). Dridi PS. examples taken off the top of my head, not pointing fingers here _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
