I don't think containers can replace modularity. They need to coexist.
If we want to create containers built on top of a distribution (no
randomly picked bits from the internet, reproducible builds, security,
...), we need a way to distribute multiple versions of the software
(module streams) and they frequently need to be built against each other
  (module contexts).

>
> 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@lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave@lists.fedoraproject.org
>> 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@lists.fedoraproject.org
>
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org