On 11/5/2019 9:17 PM, Stephen Gallagher wrote: > I'd like to gather a constructive list of the actual use-cases that > you feel Modularity is causing problems for,
Thank you, that seems like a very good way forward. > 6. We don't provide a direct solution for parallel-installability. > This is an intentional design decision, but it *is* arguably a > regression from SCL functionality, so I'll include it here. Others have made this point before, but I want to emphasise how important this is: If we decide that parallel installability is a non-goal - which IMO is a reasonable decision to make - we accept that this (via having module streams as dependencies) will at some point cause conflicts between mostly unrelated pieces of software. This breaks one of the core use cases of a software repository: C1: - if a user wants some (end-user) software, they install it via the software manager, knowing they get a reasonably up-to-date version - if they hit 'update' when asked to do so, they maintain all their software in the 'reasonably up-to-date' state - beyond that, *they don't have to care*. Given that, we need mitigation strategies - at a technical or policy level - other than containers/VMs, because those are not viable solutions for this use case*. Personally, I like a solution along the lines of what e.g. Kevin Kofler suggested earlier, that is 1) every package has a default version 2) any default version can only depend on default versions 3) the package manager distinguishes between 'install default, which happens to be version X' and 'install version X, which happens to be default', with automatic upgrade of 'X -> X' and 'default -> default' being OK and 'X -> default' or 'default -> X' requiring user intervention 4) where (2) cannot be achieved, we use compat packages as before though I freely admit that I absolutely cannot judge how difficult that is to actually implement. Christopher *i.e. for most desktop users or anyone for whom computers are tools rather than infrastructure, really.
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
