$ sudo dnf --debugsolver system-upgrade download --refresh --releasever=32

too big to attach debugdata.tar.gz
https://drive.google.com/open?id=1HqyRRzrUp29KEbeqAhURtULbttMG5iX2

Or should this be done by adding weak dependency:supplements fedora-release-workstation? Or?

Crossreferencing
https://pagure.io/fedora-workstation/issue/138

The underlying problem here is that DNF is supposed to be treating composition groups the same way it does packages by converting them on the fly into solvables representing virtual metapackages and populating them for installation/upgrade/removal.

e.g. group foo with mandatory bar, default baz would map to solvable "group(foo)" with Requires bar and Recommends baz and apply that appropriately.

That seems to not be happening properly in this case.

Thank you very much for your report. Groups are used from multiple side by multiple ways therefore any change in behaviour is quite risky. It means that what is beneficial for someone would be a problem to some one else.

Groups are implemented as quite weak objects that could be easily modified by user. You can install only part of the group or remove any package later on. Groups are not virtual packages that will enforce that all elements must be installed and after upgrade the set of components could change.

In case that you want to ensure that all elements of group are installed run `dnf group install <group, ...>`

I am really sorry but I do consider the change even for system-upgrade command as a risky.

(In reply to Neal Gompa from comment #4)
> The underlying problem here is that DNF is supposed to be treating
> composition groups the same way it does packages by converting them on the
> fly into solvables representing virtual metapackages and populating them for
> installation/upgrade/removal.
> 
> e.g. group foo with mandatory bar, default baz would map to solvable
> "group(foo)" with Requires bar and Recommends baz and apply that
> appropriately.
> 
> That seems to not be happening properly in this case.

I am really sorry but groups are not virtual packages. The present behaviour represent a long term evolution when we polished behaviour according to provided user cases. The change that you suggest will break group deployment on several architecture where some of packages are not available. People really want that packages that were removed or not installed on their systems will be not installed in future. What you describe is behaviour of virtual packages. In case that you want to use behaviour of virtual package use virtual packages, and that is what you did already. Am I correct?

I remember recent discussion about behaviour of weak deps. Several people want that after removal of weak-dep it will be not pulled in the next upgrade transaction, but they don't want to exclude it, because may be some other component will need it. Simply unresolvable problem for packages, but behaviour of groups.

Hi Jaroslav: What's the recommended alternative to bring earlyoom into F30/F31->F32 system upgrades? It's kindof an important approved feature for F32, and having a fragmented user base where a lot of people don't have it is really suboptimal. For now I'm OK with a short term work around for just this problem. Thanks!

In the general case, there's an expectation by both users and the Workstation working group (maybe other working groups) that system upgrades should produce nearly the same result as a clean install. Otherwise it's not really a system upgrade, it's just a big update that just so happens to change the major version number in a misleading way. It suggests the "real way you should do an upgrade" is just reinstall. And now I'm quickly getting off topic, so I'll direct the general (longer term) problem of upgrades and reprovisioning to https://pagure.io/fedora-workstation/issue/138

For F32->F33, let's just add a Supplements somewhere. Neal can suggest a good place.

For F33->F34, let's ask FESCo to consider this change. I agree that, ideally, changes in comps would take effect on upgrades.

I'm confused about these version numbers:
>For F32->F33, let's just add a Supplements somewhere. Neal can suggest a good place.
>For F33->F34, let's ask FESCo to consider this change. I agree that, ideally, changes in comps would take effect on upgrades.

Are you suggesting giving up on solving this for F30/F31->F32 upgrades?

No... it's just an off-by-one error. ;)

I suggest that usage of weak deps is good approach how to resolve the issue not only for F32->F33.

(In reply to Michael Catanzaro from comment #8)
> For F32->F33, let's just add a Supplements somewhere. Neal can suggest a
> good place.
> 
> For F33->F34, let's ask FESCo to consider this change. I agree that,
> ideally, changes in comps would take effect on upgrades.

I also don't like an approach to bring change to FESCo. The correct work flow is at first to convince maintainers of project about the change. Then ask FESCo.

Why the work-flow is so important, because any negative feedback will go into direction of DNF developers.

I've submitted the workaround for earlyoom as a PR: https://src.fedoraproject.org/rpms/earlyoom/pull-request/1

But that does not excuse figuring out what to do with this longer term...

*** This bug has been marked as a duplicate of bug 1845562 ***