On Wed, Oct 16, 2019 at 11:50 AM Alexander Bokovoy <abokovoy@xxxxxxxxxx> wrote: > > On ti, 15 loka 2019, John M. Harris Jr wrote: > >On Tuesday, October 15, 2019 9:40:31 PM MST Neal Gompa wrote: > >> And to be fair, while it is a hard problem to solve, it's a worthy > >> one. It makes sense and if done well, could really distinguish Fedora > >> from the rest in providing a way for codifying individual lifecycles > >> separately from the distribution. Moreover, with all the container > >> circus stuff going on, it's become even more important to enable some > >> kind of parallel availability. > > > >If "parallel availability" is the problem Modularity is trying to solve, it > >seems that Modularity is a failure. You can't install more than one version of > >a package at once. > You are mixing up parallel availability and parallel installability. > These aren't the same. Modularity does solve parallel availability > problem. It was never designed to solve parallel installability problem. And that is, in my opinion, the root source of all the issues that are currently plaguing Modularity. Parallel availability without parallel installability can only lead to problems. This is just a new, shiny version of DLL hell. Thanks, I hate it. Fabio > >Anyway, this is off topic, in my eyes, the best course of action is to simply > >require that all modules have a non-modular version in Fedora. This can also > >be done for things that are currently default modules. Sure, those who have > >existing installs with modules won't get their install fixed with the current > >code, but new installations would. That's a start. > > I don't think it is not only reasonable to have this requirement but it > is also detrimental to the project to have the requirement that > basically doubles the amount of work volunteers have to do. Simply > providing content of default modules in non-modular way ignores the fact > that you somehow need to be able to rebuild those packages and they > might depend in their build dependencies on packages from other modules, > including non-default streams. > > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland > _______________________________________________ > 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 _______________________________________________ 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
