I think we've already discussed and documented [1] this — although we haven't discussed module dependencies back then.
A) If user selects a default (or doesn't do any selection), default is followed.
B) If user selects a specific stream, that stream is followed.
So, basically, respecting user choices.
There is also a dnf bug [2].
On Fri, Oct 4, 2019 at 4:58 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> 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
Adam Šamalík
---------------------------
Red Hat
_______________________________________________ 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
