I'd like to propose a change of how DNF handles default module streams during upgrades in a way that:
a) When user chooses a specific stream, they stay on that stream. No changes here.
b) When user chooses a default stream, they stay on a default stream, potentially switching streams automatically. That's the proposed change.
The motivation behind this is consistency with how Fedora traditionally works — major distribution upgrades giving you the latest package versions — while also keeping the Modularity promise of your choices being respected.
With this change, installing a package (with "dnf install package") will behave consistently regardless of the package being in a default module stream or standalone.
As we've discussed with Daniel Mach today, the first step would be storing additional metadata about how modules have been enabled on a system. There are three distinct ways we have came up with:
1) Enabled as a specific stream explicitly (by 'dnf module install nodejs:8')
2) Enabled as a default (by 'dnf module install nodejs 'OR 'dnf install nodejs')
3) Enabled as a dependency of another module
Having such metadata would help DNF make decisions about whether or not to automatically change a particular module stream to a new default during a system upgrade.
More info here: https://pagure.io/modularity/working-documents/blob/master/f/lifecycles-upgrades-ownership/upgrades-and-modules.md
Jaroslav, I have discussed this with Daniel Mach before you took over the Modularity side of DNF. Could you please give me an idea of where does this RFE lie on your priority list, and possibly a delivery estimate? Sorry if we've already discussed this and I forgot — having this info here would help. Thanks.
I am not sure if this is a good approach because the nodule stream change is not based on strict rules but on suggestion. Additionally this is not a compatible with present philosophy that switching of a module stream is dangerous. We already have a lot of bugs that confirm that automatic switching of module stream that are not explicitly requested by user are completely incorrect. Probably we have to think about different approach. What about to implement module switching based on module metadata - using module stream obsoletes?
I had an discussion with the reporter and it resulted in conclusion that continues upgrades could be resolved by creation of an additional stream that will roll like the classical fedora during system-upgrade. Therefore I elive that the request is not needed anymore.
If I'm remembering correctly we have discussed it as an alternative approach (one of many actually), however, we haven't reached a decision. Creating an alternative stream to represent the default would have a significant impact on how things work today which we haven't thought about back then — including potential dependency breakages for modules depending on a default stream, complications on the build-system side, etc.
Let me leave this open before we decide that this approach needs to be replaced.
This definitely needs to be reopened for discussion. A previous modularity WG decision (https://pagure.io/modularity/issue/108#comment-545920) came to the determination that we need it to be possible for default streams to change on update in order to support upgrades between Fedora releases. We discussed at that time that what was needed was for us to record the reason that a stream was enabled, be it a) explicitly enabled by the user, b) enabled as a result of installing an RPM from the default stream, or c) enabled as a dependency of another module stream.
This would allow us later to use this information to decide whether it's acceptable to switch the stream during an update.
I would like to introduce solid mechanism how to handle distupgrade that will be not dependent on some hidden - nontransparent mechanism. Also the mechanism must be applicable to all distribution. I know that this is Fedora issue, but you probably have heard about RHEL8.
I believe that the primary goal of modularity is to deliver an alternative distribution content with insurance of stability.
Before we introduce dist-upgrade mechanism we have to discus and find out a strategy for:
1. Stream upgrade path
2. Stream end of life
3. Stream dist-upgrade
4. Stream lifecycle data
5. Stream obsoletes
6. Removal of streams from distribution
7. Modularity rules
a. When new module is allowed
b. When new stream is allowed to create
c. When stream must be removed
d. Number of allowed streams per module
8. Module, stream, and module platform naming policy
9. Modularity in hybrid environment
a. modules from multiple providers
b. third party non modular repositories or user content built with modular packages