> 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@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
