After removing systemd-oomd-defaults from MATE Desktop with mate-desktop-1.26.0-5.fc36 using
Recommends: earlyoom Conflicts: systemd-oomd-defaults
it turns out that user runs in another problem when using dnf groupinstall mate-desktop-environment command.
dnf groupinstall mate-desktop-environment
[root@f36 rave]# dnf groupinstall mate-desktop-environment --disablerepo results Last metadata expiration check: 0:16:37 ago on Mon May 9 20:53:45 2022. No match for group package "xorg-x11-drv-armsoc" Dependencies resolved. Problem: package mate-desktop-1.26.0-5.fc36.x86_64 requires mate-desktop-configs = 1.26.0-5.fc36, but none of the providers can be installed - package mate-desktop-configs-1.26.0-5.fc36.noarch conflicts with systemd-oomd-defaults provided by systemd-oomd-defaults-250.3-8.fc36.noarch - cannot install the best candidate for the job - conflicting requests ================================================================================ Package Arch Version Repository Size ================================================================================ Installing group/module packages: systemd-oomd-defaults noarch 250.3-8.fc36 fedora 27 k Downgrading: mate-desktop x86_64 1.26.0-3.fc36 fedora 82 k mate-desktop-configs noarch 1.26.0-3.fc36 fedora 10 k mate-desktop-libs x86_64 1.26.0-3.fc36 fedora 644 k Installing Environment Groups: MATE Desktop Installing Groups: Administration Tools base-x Core Dial-up Networking Support Fonts Guest Desktop Agents Hardware Support Input Methods MATE Multimedia Common NetworkManager Submodules Printing Support Standard Transaction Summary ================================================================================ Install 1 Package Downgrade 3 Packages
This is because systemd-oomd-defaults is in comps core group marked as default.
<group> <id>core</id> <_name>Core</_name> <_description>Smallest possible installation</_description> <default>false</default> <uservisible>false</uservisible> <packagelist> <packagereq type="mandatory">audit</packagereq> <packagereq type="mandatory">basesystem</packagereq> <cut> <packagereq type="default">systemd-oomd-defaults</packagereq> <cut> </packagelist> </group>
Here a user reported the issue https://bugzilla.redhat.com/show_bug.cgi?id=2078108#c4 What can i do to fix the problem? IHMO systemd-oomd-defaults should be optional in comps core group or moved to another group, otherwise the option in wiki page for not using systemd-oomd for spins doesn`t work. https://fedoraproject.org/wiki/Changes/EnableSystemdOomd#Should_spins_that_don.27t_put_processes_in_separate_cgroups_be_excluded_from_this_change.3F
More infos in several rhbz reports. https://bugzilla.redhat.com/show_bug.cgi?id=2068699 https://bugzilla.redhat.com/show_bug.cgi?id=2078108
@zbyszek Can you have a look here?
README says: In any group, there are four levels of packages: optional, default, mandatory, and conditional:
optional
default
mandatory
conditional
requires
It sounds like optional is not what we want. (Looking on my system, I have e.g. @development-tools installed, and I don't seem to have any of the optional packages in that group. So it seems that the docs are accurate.)
@development-tools
I don't know if comps is flexible enough to solve this nicely.
One complex approach would be to add Provides: out-of-memory-manager to systemd-oomd, earlyoom, and change comps @core to refer to that virtual provides.
Provides: out-of-memory-manager
systemd-oomd
earlyoom
@core
Comps does not understand virtual provides. It only deals with packages. So we would need to solve that in an RPM dependency somewhere.
Why not moving systemd-oomd-defaults to desktop environment groups which support cgroups and like to use systemd-oomd ?
Any new on that? The groupinstall command for a fedora supported spin is broken since several weeks. Why not adding systemd-oomd-defaults as soft dependency to systemd directly? It is part of systemd and should belongs to systemd. What is the reason to use groupinstall command for systemd-oomd-defaults? Is this really needed?
fedora supported
I created https://pagure.io/fedora-comps/pull-request/750 that should only install systemd-oomd-defaults in selected environments. PTAL and maybe test it, if you know how.
Why not adding systemd-oomd-defaults as soft dependency to systemd directly?
systemd is installed everywhere, so if systemd-oomd-defaults was added as a dependency to it, it'd be installed everywhere. The whole point of packaging it separately is to be able to pull it into the environments that want it. This is what comps is for.
My idea was only a hint push this ticket, because you didn't answer to sgallagh hint for several weeks. Well, your PR looks good to me and i am happy to test it. But i don't how to update comps temporarily on my box. @sgallagh Any idea to test PR before merging?
I tested MR. Works fine. https://pagure.io/fedora-comps/pull-request/750#comment-173902
Commit 01ba068 fixes this issue
How long does it take to see the change in f36 installation? systemd-oomd-defaults is still there in core group.
[root@mother rave]# dnf groupinfo core Last metadata expiration check: 2:54:47 ago on Sun Jul 24 14:58:36 2022. Group: Core Description: Smallest possible installation Mandatory Packages: audit basesystem <cut> Default Packages: NetworkManager dnf-plugins-core dracut-config-rescue fedora-repos-modular firewalld fwupd plymouth systemd-oomd-defaults systemd-resolved zram-generator-defaults Optional Packages: dracut-config-generic <cut>
Metadata Update from @raveit65: - Issue status updated to: Open (was: Closed)
In a branched f37 the issue is gone :)
[rave@fedora-37 ~]$ sudo dnf groupinfo core Last metadata expiration check: 0:00:35 ago on Sun Jul 24 19:48:40 2022. Group: Core Description: Smallest possible installation Mandatory Packages: <cut> Default Packages: NetworkManager dnf-plugins-core dracut-config-rescue fedora-repos-modular firewalld fwupd plymouth systemd-resolved zram-generator-defaults Optional Packages: <cut>
@raveit65 I'm confused. You reopened the issue but said the problem is gone. Can you confirm that we can close this issue?
@bcotton Issue is gone with f37 because it was a new branch. But issue still exists with older branches like f36 or f35. Changing comps information during a lifecycle of a branch doesn't work well. I think this is a well known problem. See this comment https://pagure.io/fedora-comps/issue/737#comment-807613
Log in to comment on this ticket.