Bug 1813482 - fedora-release-matecompiz-32-0.6.noarch over-writes fedora-release and fedora-system
Summary: fedora-release-matecompiz-32-0.6.noarch over-writes fedora-release and fedora...
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-release
Version: 33
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Stephen Gallagher
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1879370 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-14 00:00 UTC by George R. Goffe
Modified: 2020-09-23 08:23 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-16 12:47:50 UTC
Type: Bug


Attachments (Terms of Use)
gzip'd flat file; /var/log/secure (2.03 KB, application/gzip)
2020-09-22 04:34 UTC, George R. Goffe
no flags Details

Description George R. Goffe 2020-03-14 00:00:05 UTC
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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Peter Robinson 2020-03-16 12:47:50 UTC
That's as designed. There's only meant to be one release file installed at a time.

Comment 2 Stephen Gallagher 2020-03-16 13:27:18 UTC
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.

Comment 3 George R. Goffe 2020-03-16 17:03:41 UTC
Stephen,

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,

George...

Comment 4 Stephen Gallagher 2020-04-21 20:21:41 UTC
I've actually figured out a way to handle this properly, finally. I'm working on a patch for fedora-release now.

Comment 5 Ben Cotton 2020-08-11 15:20:56 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

Comment 6 Stephen Gallagher 2020-09-21 13:11:46 UTC
*** Bug 1879370 has been marked as a duplicate of this bug. ***

Comment 7 George R. Goffe 2020-09-22 04:34:13 UTC
Created attachment 1715624 [details]
gzip'd flat file; /var/log/secure

Comment 8 Stephen Gallagher 2020-09-22 12:45:34 UTC
(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?

Comment 9 George R. Goffe 2020-09-23 08:23:08 UTC
Stephen,

Oh man. I attched that file to the wrong bug report. Please accept my apologies for that.

Best regards,

George...


Note You need to log in before you can comment on or make changes to this bug.