Description of problem:
Running dnf -y group install --with-optional --best --allowerasing 'MATE Desktop' returns messages about conflict (overwrite?) of fedora-release and system-release files. I may be wrong but I'm not sure that is a good idea.
Version-Release number of selected component (if applicable):
Problem: problem with installed package fedora-release-32-0.6.noarch
- package fedora-release-32-0.6.noarch conflicts with system-release provided by fedora-release-matecompiz-32-0.6.noarch
- package fedora-release-matecompiz-32-0.6.noarch conflicts with system-release provided by fedora-release-32-0.6.noarch
- conflicting requests
Steps to Reproduce:
That's as designed. There's only meant to be one release file installed at a time.
To provide a little more detail, the purpose of the release files is to provide the system with all the data it needs to self-identify which "Edition" or "Spin" you are running. Normally, the "MATE Desktop" environment group is installed because you installed from the MATE Spin. This environment group needs to contain "fedora-release-matecompiz" or else it wouldn't be part of the initial install. If you later install that group manually (as opposed to the individual packages within it), it will want to install fedora-release-matecompiz as well.
The workaround is to do `dnf -y group install --with-optional --best --allowerasing --excludepkgs "fedora-release*" 'MATE Desktop'`
This will skip the conflicts and leave your system reporting its type as whatever it initially installed as.
Thanks for your info.
I understand what you've said but, I install LOTS of groups and have encountered no others who behave this way. I like the groups concept. I can say, "Get'em all" and that happens. MATE does not work this way, as you've said. I think this is not correct behavior which is why I wrote this bug report. I don't know what the "group" spec says about this but I would almost bet money that MATEs behavior is incorrect. If you start adding special handling to every group and package it makes the Systems Manager's job much more difficult. Who can possibly know all the special handling cases for over 40k packages?
Again, thanks for your info,
I've actually figured out a way to handle this properly, finally. I'm working on a patch for fedora-release now.
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.
*** Bug 1879370 has been marked as a duplicate of this bug. ***
Created attachment 1715624 [details]
gzip'd flat file; /var/log/secure
(In reply to George R. Goffe from comment #7)
> Created attachment 1715624 [details]
> gzip'd flat file; /var/log/secure
What should I be looking at here?
Oh man. I attched that file to the wrong bug report. Please accept my apologies for that.