Dne 30. 03. 20 v 19:20 Zbigniew Jędrzejewski-Szmek napsal(a):
On Mon, Mar 30, 2020 at 10:30:51AM -0400, Ben Cotton wrote:
<pre>
document: TBD
version: 1
data:
# A string representing UTC date in ISO 8601 format: YYYY-MM-DD[T ]HH:MMZ
# When merging, entries with a newer 'modified' value will override
any earlier values.
# MANDATORY
modified: 2020-03-19T23:26Z
# A boolean option to cancel/reset all previously specified obsoletes
# Example: repo 'fedora' has Obsoletes:nodejs:12; we want to bring
nodejs:12 back in 'updates'
# If used, following options will be ignored: eol_date, obsoleted_by
# OPTIONAL
<TBD>: <bool>
What obsoletes would be covered by this? Those for this particular stream?
Obsoletes for specified Name, Stream and Context(s) (if present).
# A string representing a Name of a module that is EOLed
# MANDATORY
module: nodejs
# A string representing a Stream of a module that is EOLed
# MANDATORY
stream: 11
# A string representing a Context of a module that is EOLed
# If not specified, all contexts get EOLed.
# NOTE: consider specifying a list of contexts
# OPTIONAL
context: aabbccddee
# A string representing UTC date in ISO 8601 format: YYYY-MM-DD[T ]HH:MMZ
# It is strongly recommended to keep HH:MM to 00:00.
# If not specified, the module is EOLed immediately.
OPTIONAL
eol_date: 2020-03-19T00:00Z
Normally we want the obsoletes to happen when doing a 'dnf system-upgrade'
operation, and not based on time. Does this allow us to tell dnf for this
happen during an upgrade, but not before?
There are scenarios when you don't run system-upgrade and you still want
the obsoletes. Consider Rawhide. We'll need a way how to trigger modular
obsoletes even during normal upgrade/distro-sync transactions.
Setting eol_date to the future allows informing a user about upcoming
obsoleting event so they can eventually migrate manually.
# A string describing the change, reason, etc.
# MANDATORY
message: "Module stream nodejs:11 is no longer supported. It is
recommended to switch to nodejs:12"
# If a stream is not EOLed but Obsoleted, provide details about the
obsoleting stream:
# OPTIONAL
obsoleted_by:
module: nodejs
stream: 12
Is the obsoleting module enabled automatically?
Kind of; I expect following behavior:
* print a warning by default and have a possibility to manually turn
stream obsoletes on (must have on Rawhide)
* an automated stream switch during system-upgrade
== User Experience ==
Fedora users experience upgradability problems when upgrading to Fedora 32
when they have any module streams enabled.
If a stream no longer exists on the version of Fedora they are upgrading to,
DNF used to error out on resolving modular dependencies which was a
clear release blocker.
To workaround this case, all module streams are reset during the system upgrade.
By doing this, modularity users lose information about enabled streams
and they need to re-enable them by hand.
This Change aims at removing the upgradability problems and allowing
Fedora modularity users
to upgrade their systems while keeping their streams enabled, reset or
switched (obsoleted)
according to newly provided modular metadata.
Thanks, that sounds like a reasonable UX.
Zbyszek
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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-le...@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
