+++ This bug was initially created as a clone of Bug #1688462 +++

As discussed in https://bugzilla.redhat.com/show_bug.cgi?id=1656509 , it seems to be generally the case that any upgrade which involves modular content will not work correctly unless the 'module_platform_id' option is explicitly set to the correct value for the target release. e.g. when upgrading to Fedora 30, this is needed:

sudo dnf system-upgrade download --refresh --releasever=30 --setopt='module_platform_id=platform:f30'

It was generally agreed by the Modularity WG and others (including QA) that this is not acceptable: upgrades should work as they did before modularity, i.e. only --releasever should need to be passed.

I'm setting the version here to 29, but in fact I suspect we should put the fix in all active branches (including F28) so upgrades from F28 to F30, for e.g., work?

Proposing as an F30 Beta blocker, but I suspect we may decide to make this a Beta FE and a Final blocker (on the basis that it might be OK to ask people to do the --setopt for a Beta, but not for a final release).

--- Additional comment from Petr Pisar on 2019-03-14 15:43:34 UTC ---

Maybe it's time for specifying an upgrade path between module streams. platform:f29 is unsupported in Fedora 30. Thus Fedora 30 modular repository should specify that platform:f30 replaces platform:f29. With this metadata available DNF could switch the stream automatically on system upgrade. Something like Obsoletes in RPM. This feature should be available for all modules. Not only platform. Because other modules' streams are also subjects of becoming end-of-life.

--- Additional comment from Geoffrey Marr on 2019-03-18 18:27:51 UTC ---

Discussed during the 2019-03-18 blocker review meeting: [1]

The decision to classify this bug as a "RejectedBlocker (Beta)", a "RejectedFreezeException (Beta)", and an "AcceptedBlocker (Final)" was made as we agreed that the workaround here (using --setopt) is OK for Beta, but not acceptable for Final, so this is accepted as a Final blocker. We do not grant a Beta FE as we don't think fixing this late for Beta is worth the risk of taking more DNF change.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-03-18/f30-blocker-review.2019-03-18-16.03.txt

--- Additional comment from Jaroslav Mracek on 2019-04-02 08:05:45 UTC ---

I propose to drop Platform ID

Platform ID is in many aspect redundant to releasever or to dependencies generated during rpm builds

Pros:
The simplest implementation
Platform incompatibility handled by package requires and releasever (RHEL-7)
No errors

Negs:
Impossible to play with names of the platform
Increase importance of proper delivery channels (identical to RHEL7/Fedora27-)

--- Additional comment from Jaroslav Mracek on 2019-04-03 08:19:17 UTC ---

To resolve the bug we need a decision from Modularity team about a future of the Platform ID. So far the subject is under discussion with Modularity team without a final decision. Please could you provide additional information?

--- Additional comment from Kostya Vasilyev on 2019-04-03 19:07:09 UTC ---

Kind of same thing with Fedora XFCE (+ updates + updates testing)

----------------------

sudo dnf system-upgrade download --refresh --releasever=30
Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y
Fedora 30 openh264 (From Cisco) - x86_64                                      5.0 kB/s | 3.0 kB     00:00    
Fedora Modular 30 - x86_64                                                     20 kB/s |  19 kB     00:00    
Fedora Modular 30 - x86_64 - Updates                                           70 kB/s | 3.0 kB     00:00    
Fedora Modular 30 - x86_64 - Test Updates                                      49 kB/s | 2.4 kB     00:00    
Fedora 30 - x86_64 - Test Updates                                             104 kB/s | 4.7 kB     00:00    
Fedora 30 - x86_64 - Updates                                                   25 kB/s |  25 kB     00:00    
Fedora 30 - x86_64                                                             15 kB/s |  14 kB     00:00    
google-chrome                                                                  16 kB/s | 1.3 kB     00:00    
MongoDB Repository                                                            6.7 kB/s | 2.5 kB     00:00    
Scooter Software                                                              8.9 kB/s | 2.9 kB     00:00    
skype (stable)                                                                 14 kB/s | 2.9 kB     00:00    
Sublime Text - x86_64 - Dev                                                   6.2 kB/s | 2.9 kB     00:00    
Visual Studio Code                                                            8.4 kB/s | 2.9 kB     00:00    
Modular dependency problems:

 Problem 1: conflicting requests
  - nothing provides module(platform:f30) needed by module newsboat:latest:3020190307162417:a5b0195c-0.x86_64
 Problem 2: conflicting requests
  - nothing provides module(platform:f30) needed by module newsboat:latest:3020190325084033:a5b0195c-0.x86_64
 Problem 3: conflicting requests
  - nothing provides module(platform:f30) needed by module avocado:stable:3020190304180315:a5b0195c-0.x86_64
 Problem 4: conflicting requests
  - nothing provides module(platform:f30) needed by module bat:latest:3020190307100850:e50d0d19-0.x86_64
 Problem 5: conflicting requests
  - nothing provides module(platform:f30) needed by module dwm:6.1:3020190304180429:a5b0195c-0.x86_64
 Problem 6: conflicting requests
  - nothing provides module(platform:f30) needed by module exa:latest:3020190306064823:e50d0d19-0.x86_64
 Problem 7: conflicting requests
  - nothing provides module(platform:f30) needed by module ffsend:latest:3020190317224628:a5b0195c-0.x86_64
 Problem 8: conflicting requests
  - nothing provides module(platform:f30) needed by module fish:3:3020190301191132:602da195-0.x86_64
 Problem 9: conflicting requests
  - nothing provides module(platform:f30) needed by module gimp:2.10:3020190304180601:a5b0195c-0.x86_64
 Problem 10: conflicting requests
  - nothing provides module(platform:f30) needed by module heatseeker:latest:3020190309110310:a5b0195c-0.x86_64
 Problem 11: conflicting requests
  - nothing provides module(platform:f30) needed by module hyperfine:latest:3020190318171218:a5b0195c-0.x86_64
 Problem 12: conflicting requests
  - nothing provides module(platform:f30) needed by module libgit2:0.27:3020190304180745:a5b0195c-0.x86_64
 Problem 13: conflicting requests
  - nothing provides module(platform:f30) needed by module meson:latest:3020190310183600:36245242-0.x86_64
 Problem 14: conflicting requests
  - nothing provides module(platform:f30) needed by module minetest:5:3020190308194723:a5b0195c-0.x86_64
 Problem 15: conflicting requests
  - nothing provides module(platform:f30) needed by module ninja:latest:3020190304180949:a5b0195c-0.x86_64
 Problem 16: conflicting requests
  - nothing provides module(platform:f30) needed by module ripgrep:latest:3020190306064851:a5b0195c-0.x86_64
 Problem 17: conflicting requests
  - nothing provides module(platform:f30) needed by module rpick:latest:3020190313083345:a5b0195c-0.x86_64
 Problem 18: conflicting requests
  - nothing provides module(platform:f30) needed by module standard-test-roles:3.0:3020190319161255:a5b0195c-0.x86_64
 Problem 19: conflicting requests
  - nothing provides module(platform:f30) needed by module stratis:1:3020190306064421:a5b0195c-0.x86_64
Error: 
 Problem: problem with installed package tortoisehg-4.6.1-1.fc29.noarch
  - package tortoisehg-4.6.1-2.fc30.noarch requires mercurial < 4.7, but none of the providers can be installed
  - tortoisehg-4.6.1-1.fc29.noarch does not belong to a distupgrade repository
  - mercurial-4.5.3-1.fc29.x86_64 does not belong to a distupgrade repository
(try to add '--skip-broken' to skip uninstallable packages)


----------------


Adding --setopt='module_platform_id=platform:f30 seemingly worked.

I had to un-install "mercurial" and "tortoisehg" (don't know what the deal is, they are still present in F30) - will add back once I'm in F30.

--- Additional comment from Jaroslav Mracek on 2019-04-05 07:35:55 UTC ---

According to discussions with Modularity team we will resolve the problem using additional detection of a platform ID from package provides (metadata). Because the change will have impact not only on DNF but also on other components (PackageKit, microdnf, satellite), in Fedora 29, 30, and 31 it requires a system wide change. I believe that without an approval we cannot release the change.

--- Additional comment from Stephen Gallagher on 2019-04-10 13:45:41 UTC ---

The DNF team and Modularity teams agreed on the approach to deal with this. We will add a new virtual Provides to the system-release package. This will be `Provides: base-module(platform:f29)`. DNF will then follow this ordering for determining the relative priority of the various ways the module can be provided:


1) Specified at commandline with --setopt
    Always prefer the user's explicit override
    
2) The virtual Provides from the latest `system-release` package in the enabled repos.
    This will deal with upgrades and enabling the Rawhide repo from a stable release. The net result here will be that upgrading any module stream to one that requires a newer platform will update the system-release package to that new platform.
    
3) /etc/os-release
    In the event that no enabled repos provide the virtual Provides, fall back to reading it from /etc/os-release
    
4) /usr/lib/os-release
    In the event that no enabled repos provide the virtual Provides and /etc/os-release doesn't exist (e.g. OSTree systems), fall back to reading it from /usr/lib/os-release

Agreed to by Stephen Gallagher, Petr Sabata, Adam Samalik, Jaroslav Mracek and Stephen Tweedie

--- Additional comment from Kevin Fenzi on 2019-04-10 17:54:47 UTC ---

This sounds good to me, is this for f30+ ? or also pushed to f29?

It would be super nice if this was done before freeze next week...

--- Additional comment from Stephen Gallagher on 2019-04-10 19:58:19 UTC ---

(In reply to Kevin Fenzi from comment #8)
> This sounds good to me, is this for f30+ ? or also pushed to f29?
> 
> It would be super nice if this was done before freeze next week...

The fedora-release side of things is done and available for F29+. The DNF portion will need to be pushed to F29 as well or upgrades from F29->F30 will still have this bug (which we accepted as a blocker). I'm not going to speak for jmracek as to whether they can have it done in the next couple days.

The remaining question from Jaroslav is that he'd like to have someone (FESCo) make the decision that fixing this bug is worth the degree of change it's going to require. In theory, we *could* decide that the --setopt workaround is safer for F30, but I personally think that the resulting upgrade problems will cause more trouble for Fedora. I'll open a FESCo ticket asking for an emergency vote, just to be sure.

--- Additional comment from Fedora Update System on 2019-04-10 20:12:15 UTC ---

fedora-release-29-10 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-425159a57e

--- Additional comment from Fedora Update System on 2019-04-10 20:12:18 UTC ---

fedora-release-30-0.26 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-78e132ecd0

--- Additional comment from Stephen Gallagher on 2019-04-10 22:13:51 UTC ---

Adjusting status back to NEW. The fedora-release change is necessary but not sufficient to fix this.

FESCo voted quickly in https://pagure.io/fesco/issue/2118 to approve the proposed solution, so the DNF team is encouraged to go ahead as soon as possible.

--- Additional comment from Fedora Update System on 2019-04-12 02:47:27 UTC ---

fedora-release-30-0.26 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-78e132ecd0

--- Additional comment from Fedora Update System on 2019-04-12 03:56:11 UTC ---

fedora-release-29-10 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-425159a57e