I have to ask, given containers are so popular and can deal with any dependency without conflicting with system installed binaries, should we really continue with this very complicated modular design ? Shouldn't we go back to have default packages and then defer to "containers" for applications (and their dependencies) that need to deviate from system defaults for any reason ? Simo. On Fri, 2019-10-04 at 10:57 -0400, Stephen Gallagher wrote: > Right now, there are two conflicting requirements in Fedora Modularity > that we need to resolve. > > 1. Once a user has selected a stream, updates should follow that > stream and not introduce incompatiblities. Selected streams should not > be changed without direct action from the user. > 2. So far as possible, Modularity should be invisible to those who > don't specifically need it. This means being able to set default > streams so that `yum install package` works for module-provided > content. > > Where this becomes an issue is at system-upgrade time (moving from > Fedora 30->31 or continuously tracking Rawhide). Because of > requirement 1, we cannot automatically move users between streams, but > in the case of release upgrades we often want to move to a new default > for the distribution. > > > The Modularity WG has generally agreed that we want and need to > support behavior of the following use-cases: > > > Use Case 1: > > On Fedora 30, user Alice runs > > yum install Foo > > The package "Foo" is provided by a module "foo" with a default stream > "v1.0". Because it's available in a default stream, the package is > installed and the module stream "foo:v1.0" is implicitly enabled for > the system. > > > > Fedora 31 is released. On Fedora 31, the module "foo" has a new > default stream "v1.1". When upgrading from Fedora 30 to Fedora 31, > Alice expects the package Foo she installed to be upgraded to version > 1.1, because that's what would have happened if it was provided as a > package from the non-modular repositories. > > > > Use Case 2: > > On Fedora 30, user Bob runs > > yum enable foo:v1.0 > > In this case, the "v1.0" stream of the "foo" module has a dependency > on the "v2.4" stream of the "bar" module. So when enabling "foo:v1.0", > the system also implicitly enables "bar:v2.4". > > > > Fedora 31 is released. On Fedora 31, the module stream "foo:v1.0" now > depends on "bar:v2.5" instead of "bar:v2.4". The user, caring only > about "foo:v1.0" would expect the upgrade to complete, adjusting the > dependencies as needed. > > > At Flock and other discussions, we've generally come up with a > solution, but it's not yet recorded anywhere. I'm sending it out for > wider input, but this is more or less the solution we intend to run > with, barring someone finding a severe flaw. > > Proposed Solution: > > What happens today is that once the stream is set, it is fixed and > unchangeable except by user decision. Through discussions with UX > folks, we've more or less come to the decision that the correct > behavior is as follows: > > * The user's "intention" should be recorded at the time of module > enablement. Currently, module streams can exist in four states: > "available, enabled, disabled, default". We propose that there should > be two additional states (names TBD) representing implicit enablement. > The state "enabled" would be reserved for any stream that at some > point was enabled by name. For example, a user who runs `yum install > freeipa:DL1` is making a conscious choice to install the DL1 stream of > freeipa. A user who runs `yum install freeipa-client` is instead > saying "give me whatever freeipa-client is the default". > > * The state `dep_enabled` would be set whenever a stream becomes > enabled because some other module stream depended on it. This state > must be entered only if the previous state was `default` or > `available`. (We don't want `enabled` or `disabled` streams being able > to transition to this state.) > > * The state `default_enabled` would be set whenever a stream becomes > enabled because a transaction pulled in a package from a default > stream, causing it to be enabled. This state must only be entered if > the previous state was `default` or `dep_enabled`. We don't want > `enabled` or `disabled` to be able to transition to `default_enabled`. > If a user requests installation of a package provided by a stream > currently in the `dep_enabled` state, that stream should transition to > the `default_enabled` state (meaning that now the user would expect it > to be treated the same as any other default-enabled stream). > > * When running `dnf update`, if a module stream's dependency on > another module changes to another stream, the transaction should cause > that new stream to be enabled (replacing the current stream) if it is > in the `dep_enabled` state. > When running `dnf update` or `dnf system-upgrade`, if the default > stream for a module installed on the system changes and the module's > current state is `default_enabled`, then the transaction should cause > the new default stream to be enabled. > > * If stream switching during an update or upgrade would result in > other module dependency issues, that MUST be reported and returned to > the user. > > This requires some constraints to be placed on default and dependency changes: > > * Any stream upgrade such as this must guarantee that any artifacts of > the stream that is exposed as "API" MUST support RPM-level package > upgrades from any previous stream in this stable release. (Example: > "freeipa:DL"1 depends on a the "pki-core:3.8" stream at Fedora 30 > launch. Later updates move this to depending on "pki-core:3.9" and > even later "pki-core:3.10". In this case the packages from > "pki-core:3.10" must have a safe upgrade path from both "pki-core:3.8" > and "pki-core:3.9" since we cannot guarantee or force our users to > update regularly and they might miss some of the intermediate ones. > _______________________________________________ > 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 -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ 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
