On Fri, Oct 4, 2019 at 10:57 AM 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.
>
>
One thing that came up in this thread was the lack of a concept of
"Obsoletes" in the modular metadata. This was initially done
intentionally, because we had the original constraint 1) above
("Selected streams should not be changed without direct action from
the user.").
However, given that we're talking about the need to migrate defaults
anyway, I think it may be worth considering adding something like an
Obsoletes mechanism, but with a little more nuance.
Alternate Proposal:
Most things from the original proposal in the first message of this
thread remains the same except:
Module stream metadata would gain two new optional attributes,
"upgrades:" and "obsoletes:".
If the "upgrades: <older_stream>" field exists in the metadata, libdnf
should switch to this stream if the following conditions are met:
1) Changing the stream would not introduce conflicts.
2) The stream is marked as `default_enabled` or `dep_enabled`.
The "obsoletes: <older_stream>" field would be stronger. Its use
should require a special exemption (with a strong justification) and
it would cause libdnf to switch from that stream to this one
*unconditionally* (failing the transaction if that transition would
cause conflicts). This would essentially be an "emergency escape" if
we need it.
This would obviate the need for handling changes to the default stream
in favor of having explicit transitions encoded by the packager into
the module metadata.
_______________________________________________
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
