----- Original Message ----- > From: "Stephen Gallagher" <sgallagh@xxxxxxxxxx> > To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Tuesday, November 5, 2019 3:17:28 PM > Subject: Modularity: The Official Complaint Thread ~snip~ > 1. Once enabled, a module stream is never changed on behalf of the > user. While this adds some strong guarantees to those who want to run > applications built from those streams, the presence of default streams > changes the expected upgrade behavior for users. Traditionally, at > upgrade a user would get the new release's most-updated version of all > packages currently on their system. With Modularity, if one of their > packages comes from a default stream and that stream is not the > default for the next release, they will stay on the current stream (or > be blocked from upgrading, if the current stream is unavailable on the > next release). [2] Special care needs to be taken to make sure we discuss what happens when a _module maintainer_ wants to switch the module stream of one of its dependencies, especially a dependency the user never specifically selected a stream for. That should be an allowed and fully supported use case. This was the pki-core<->idm module fiasco that was never resolved by DNF/Modularity. I'd post the bug number but the bug isn't public. So perhaps split this into: 1. How does a _user_ change module streams during upgrade? 2. How does the _maintainer_ change module streams of a dependent module? (module a -dep-> module b -- change stream of b from 1 to 2) IMO, without a resolution in Fedora we'll never get one in RHEL. - Alex _______________________________________________ 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