Since https://pagure.io/fm-orchestrator/issue/1342 was closed because it was not a correct place to keep such architecture discussion, moving the rest of the discussion here.

To sum up the discussion there:
* there are some streams where upgrade path can be defined
* there are some streams where we cannot tell whether something is newer than the other and so we cannot speak about upgrading

There are also these related issues reported:
https://pagure.io/fedora-docs/modularity/pull-request/64
https://pagure.io/modularity/issue/145

CC @jaruga @ignatenkobrain @ngompa @mprahl @jkaluza @vondruch

@hhorak

there are some streams where we cannot tell whether something is newer than the other and so we cannot speak about upgrading

Does "dnf module" command really need to tell users that one stream is "newer" than another stream or that one stream is upgrading from another stream?
There are no "newer" and "upgrading" concepts for "dnf module" (modularity) so far.

The way $ sudo dnf --allowerasing distro-sync [RPM]... is not enough?

Could tell us more about your expectations and concerns?

My concerns with $ sudo dnf --allowerasing distro-sync [RPM]... are:

• if used without [RPM] argument, then also packages that are not part of the module might be removed/downgraded..
• if used with [RPM] argument, then user needs to know what packages are installed from the module
• packages missing in the new stream are not removed

This is my expectation how it should work:

• I have module ruby:2.5 enabled and some packages from that module installed

• I run $ sudo dnf module-stream-switch ruby:2.6 (just for demonstration, the command might look differently) to tell dnf to do these things:

  • disable ruby:2.5 and enable ruby:2.6 stream
  • update/downgrade packages that are part of both, ruby:2.5 and ruby:2.6 streams, and are installed
  • remove all packages that are part of the ruby:2.5 stream and are not part of ruby:2.6 stream (maybe only if --allow-erasing is specified)

So, it is mostly same as the distro-sync from the comment above, but more convenient and does only what user is requesting.

@hhorak thanks for your explanation and clarification. I can understand your concerns.
The command to switch the stream will give users a better and safer user experiences.

Modularity and dnf team, could you consider to add this as new feature?

My preference for this kind of command is dnf module switch :)

@jaruga We've discussed this before and I don't remember all of the details, but I think the problem was that we didn't have all of the information we would need at the correct times to do the crossover sync. When we worked out all of the edge-cases, it had ultimately boiled down to "so close to dnf distro-sync that it wasn't worth doing".

@dmach @jmracek Can you remind us about the specifics, please?

In Fedora we don't see the origin of packages, because they are disappearing from metadata. It means that metadata from yesterday could have foo part of module x, but today there is no foo at all.

Is there any rule or guidelines that forbid such changes?

I see it might not work in 100% cases, but if we know about specific cases now that can be implemented better, to give users better UX in 80% cases they meet, we should.