Bug 1609294

Summary:	cinnamon-desktop-environment definition doesn't know that xreader obsoleted nemo-extension-xreader
Product:	[Fedora] Fedora	Reporter:	Andre Robatino <robatino>
Component:	comps	Assignee:	Stephen Gallagher <sgallagh>
Status:	CLOSED ERRATA	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	28	CC:	awilliam, kevin, vpavlin
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-07-27 22:22:04 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Andre Robatino 2018-07-27 13:27:00 UTC

Description:

[root@lenovo-pc ~]# dnf groupinstall cinnamon-desktop-environment
Last metadata expiration check: 2:31:10 ago on Fri 27 Jul 2018 06:53:45 AM EDT.
Environment 'Cinnamon Desktop' is already installed.
Group 'base-x' is already installed.
Group 'Cinnamon' is already installed.
Group 'Core' is already installed.
Group 'Dial-up Networking Support' is already installed.
Group 'Fonts' is already installed.
Group 'Guest Desktop Agents' is already installed.
Group 'Hardware Support' is already installed.
Group 'Input Methods' is already installed.
Group 'Multimedia' is already installed.
Group 'Common NetworkManager Submodules' is already installed.
Group 'Printing Support' is already installed.
Group 'Standard' is already installed.
No match for group package "xorg-x11-drv-omap"
No match for group package "ppc64-utils"
No match for group package "xorg-x11-drv-armsoc"
No match for group package "gstreamer1-plugin-mpg123"
Dependencies resolved.
================================================================================
 Package                     Arch        Version              Repository   Size
================================================================================
Installing group packages:
 nemo-extension-xreader      x86_64      1.6.2-2.fc28         fedora       19 k
Downgrading:
 xreader                     x86_64      1.6.2-2.fc28         fedora      1.1 M

Transaction Summary
================================================================================
Install    1 Package
Downgrade  1 Package

Total download size: 1.1 M
Is this ok [y/N]: N
Operation aborted.
[root@lenovo-pc ~]#

A recent version of xreader obsoleted nemo-extension-xreader. An update causes xreader to be updated again and remove nemo-extension-xreader.

Packages to be added: 

Comps group:  

Default: 

Mandatory: 

Visible: 

Multi-lib: 

Need to be present for arches:

Comment 1 Adam Williamson 2018-07-27 22:22:04 UTC

Should be fixed by https://pagure.io/fedora-comps/c/f63862d7f8a92e989ebff14b143d05ad781242d3?branch=master .

Comment 2 Andre Robatino 2018-07-30 20:56:58 UTC

(In reply to Adam Williamson from comment #1)
> Should be fixed by
> https://pagure.io/fedora-comps/c/
> f63862d7f8a92e989ebff14b143d05ad781242d3?branch=master .

Thanks. Do you know how long these changes typically take to become active? The change you made in https://bugzilla.redhat.com/show_bug.cgi?id=1609292#c1 was active in the next Rawhide compose, but this one still isn't (in F28).

Comment 3 Adam Williamson 2018-07-30 21:37:24 UTC

well...it's a bit complicated, for f28. there are the comps for the 'fedora' repo, which will never change, because they're frozen. changes to fedora-comps git get applied to the comps for updates and updates-testing, I believe. I do not know how dnf then reconciles all those different sources of comps data together. It's possible that because 'nemo-extension-xreader' is listed in the 'fedora' comps, dnf will always try to pull it in, even if it's *not* in the 'updates' / 'updates-testing' comps.

If that's the case...perhaps we'll have to make xreader Provide nemo-extension-xreader? But even that may not be sufficient.

Comment 4 Andre Robatino 2018-09-17 04:38:07 UTC

This issue continues. Should this be reopened as a bug against dnf? Or try using a Provide: first?

Comment 5 Adam Williamson 2018-09-17 15:34:34 UTC

I guess we could try using a Provides...

Comment 6 Adam Williamson 2018-09-17 15:35:25 UTC

or, hmm, no, that probably wouldn't work, IIRC comps only goes by binary package name, it doesn't handle Provides.

We could possibly call this a bug in dnf or libcomps, I guess...