On Tue, 5 Mar 2019 09:08:19 +0100 Adam Samalik <asamalik@xxxxxxxxxx> wrote: > On Mon, Mar 4, 2019 at 10:26 PM Michael Cronenworth <mike@xxxxxxxxxx> > wrote: > > Why should I care? Please, win me over. (I'm being serious.) > > > > I think you should care if: > > a) You need to maintain multiple versions of the same app/runtime/set > of tools tools in Fedora (or an alternative to something that already > exists), or > b) You only want to maintain one source branch per package for all > Fedora releases, or > c) You could benefit from having a build recipe in case you maintain > app/runtime/set of tools tools represented by multiple packages that > need to be built in the right order > > But if any of the above is something that you need/want to do, then > Modularity won't help you nor hurt you in any way. > > > > I view the current RPM system as reliable, standard, and > > well-documented. It's > > served me and the people I know that use it well for decades. I view > > Modularity as > > an answer to a question no one asked. It presents new problems that > > never existed > > and has been somewhat silently taking over RPM-land with very little > > community > > involvement. I'm not a packager, I only follow devel to see what is coming down the pipe as a user. I'm concerned about modularity. Like Michael, I find rpm works fine for my use case, an individual workstation. I have a couple of comments, but since I am not the target of modularity, take them as curiosity. It seems that modularity will create one more layer of indirection, so security holes will be more prone to exist and be harder to find and fix for the user, particularly on mixed rpm / modularity systems. Modularity seems to be a workaround to avoid making the system fully multi version. Admittedly, that is a lot of work, gcc has to be modified to create a dictionary of libraries and api calls needed in executables, libraries have to be modified to publish their api calls, the kernel has to sort through multiple versions of a binary checking priorities (somehow). rpm has to be modified to allow multiple version installation, and to do library checking to be sure that an existing library will cover needed calls. There has to be garbage collection for libraries no longer needed by executables on the system. etc. The up side is there is no more shared library so numbers for libraries, so updates will *always* succeed, and the garbage collector will take care of no longer needed packages. Is the following a good summarization of the purpose of modularity? Modularity is a workaround using the pareto principle to get 80% of the benefits of multi version with only 20% of the work. Would it be practical to have a new hierarchy under /usr for modularity, say /usr/mod, or move the current /usr to /usr/rpm and let /usr be for modularity? This would make it easier to specify which version of a binary to run, and which should be default in the path. So, if I install a module with old, possibly insecure components, because I need it for legacy purposes, I can specify it in a script, and let the newer version be the default for general use. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
