Re: Modularity and the system-upgrade path

[Przemek Klosowski via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx>]

On 10/17/19 12:27 PM, Stephen John Smoogen wrote:

people are going to add things into their modules to make whatever
software they need. If I find that I need libfoo2-2.34 in libreoffice
and you need libfoo2-2.40 in evolution.. then only one of the two
modules can be installed.You can either have libreoffice or you can
have evolution.

Cap't Obvious here, but I think the logic is like this:

1. in an ideal world software would build and run with the latest-greatest versions of everything as a default
   
2. ...but in the real world we have to sometimes chose a non-default versions. There's enough of this happening that we can't just say we'll work hard until we reach 1.
3. modularity allows choosing non-default versions, which is great for a particular application, but conflicts with other apps, forcing us to choose only one of them. This provides a working solution for at least some people, so it's useful for e.g. Redhat, but it makes life hard for an end-user that just wants to have a system with a complete set of software
   
4. such modularized solutions can be combined into usable systems by either containers or cooperating VMs, but again, it's harder for end-users and has other undesirable consequences, e.g. complicates security management
   

The logical conundrum of modularity is that when we require non-default modules, then it logically follows that there will be conflicts (if there weren't, we wouldn't need modules) and so we are forced all the way into 4. unless we're lucky, and happen not to need the packages that depend on conflicting modules.

The bottom line is that modularity is useful, but in the sense of insurance or fire extinguishers: it's good to have them but we should really hope that we won't have to use them.

If only there was a way to limit the scope of the non-default modules to their dependencies--by using private library directories or something like that? I think it would solve the problem of parallel installation, and would simplify upgrades by making it explicit what pulled them in in the first place, and place joint responsibility for updates on these subsystems. This is essentially bundling, but exposed in the packaging system so it's more manageable.

_______________________________________________
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