On Tue, Mar 5, 2019 at 11:01 AM stan <upaitag@xxxxxxxx> wrote: > > 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. > Modules are merely collections of rpms built in a special way. Sometimes that's with macro definitions to force overrides for specific configurations, and sometimes that's with filtering packages, or customizing build and runtime content. > 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. > RPM already allows multiversion installation with the caveat that there are no file collisions. The other aspects are things that can be handled by DNF. Modules are only about some of those use cases. The other major cases involve build-time customization and partitioning built packages into supportable or non-supportable groups. > 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. No. It should be possible for modular content to become non-modular and vice versa. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
