On Fri, Oct 4, 2019 at 10:57 AM Stephen Gallagher <sgallagh(a)redhat.com> 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.