Bug 1609294 - cinnamon-desktop-environment definition doesn't know that xreader obsoleted nemo-extension-xreader
Summary: cinnamon-desktop-environment definition doesn't know that xreader obsoleted n...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: comps
Version: 28
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Stephen Gallagher
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-27 13:27 UTC by Andre Robatino
Modified: 2018-09-17 15:35 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2018-07-27 22:22:04 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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...


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