Fix Fedora upgradability issues when upgrading systems with module streams enabled.
I disagree on adding Obsoletes for a number of reasons. If a module is not in any repos anymore and is blocking upgrade, DNF should simply remove it. Any automated handling of replacing one module stream by another is very dangerous and must be handled manually.
Also the EOL already is part of modulemd, and this part I agree should be properly filled in and handled by DNF.
Unfortunately Change proposal does not mention any specifics how the fields are supposed to be handled.
-1 on the change. Please provide all possible scenarios related to these new fields and what DNF would do in those cases.
Metadata Update from @psabata: - Issue tagged with: meeting
* #2364 F33 System-Wide Change: Introduce module Obsoletes and EOL (contyk, 15:14:16) * This topic needs more discussion and responses from the proposal owners. We'll discuss this next week. (contyk, 15:16:44)
JFYI @dmach is aware that we wait for a reply and he plans to get back to that soon. I am removing the meeting tag for now, because there is nothing to discuss.
@ignatenkobrain's vote prevents this to be autoapproved if stalled.
Metadata Update from @churchyard: - Issue untagged with: meeting
No updates in
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/D647RCO77OBNVLD5RBCACXPVOQKPBBKP/
Metadata Update from @churchyard: - Issue tagged with: stalled
I have updated the Change with proposed behavior to make clear what's the outcome:
Proposed dnf behavior: * dnf system-upgrade will automatically follow module Obsoletes and EOL, resetting or switching streams accordingly * other dnf commands will not follow Obsoletes and EOL automatically; user will have to manually enable an option (see the paragraph above); this should help Rawhide users to handle module upgradability problems because it's a rolling release and they do not run system upgrade.
eol in modulemd has been replaced with servicelevels. It might solve only the EOL part of our proposal. It does not handle Obsoletes.
We would prefer to handle stream Obsoletes and ideally also EOL with external metadata rather than modulemd directly. @ignatenkobrain If you have a better idea, please prepare a counter-proposal explaining your approach in sufficient detail.
Since default modular streams are banned, this is IMHO basically a self contained change that will only affect a small group of power users who have modular streams manually enabled and update from Fedora 33 to 34 or 35. I believe that the change owners will handle this quite well and if there is breakage affecting non-modular users, there is planty of time to fix that.
You have my +1.
Metadata Update from @churchyard: - Issue untagged with: stalled
@churchyard good point. without default streams this will only affect users who should know what they're doing anyway. The clarifications sound good to me, so have one more +1 vote.
+1 to convert this change to a self-contained and to the change itself.
Since Igor changed his -1, I count the vote as (+3,0,-0) after ...a long time... and will process this change as accepted.
Metadata Update from @bcotton: - Issue tagged with: pending announcement
I missed the updates to this ticket somehow, but I'm also +1
I forgot to look at the latest version, sorry.
+1 from me too.
Metadata Update from @sgallagh: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Metadata Update from @bcotton: - Issue untagged with: F33 - Issue set to the milestone: Fedora 33
Log in to comment on this ticket.