Bug 1116666 - handling groups installed by Yum
Summary: handling groups installed by Yum
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf   
(Show other bugs)
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Ales Kozumplik
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2014-07-07 02:03 UTC by Chris Murphy
Modified: 2014-09-30 23:42 UTC (History)
5 users (show)

Fixed In Version: dnf-0.6.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-08-12 07:16:41 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
debugdata.tgz (4.34 MB, application/x-compressed-tar)
2014-07-07 02:03 UTC, Chris Murphy
no flags Details

Description Chris Murphy 2014-07-07 02:03:48 UTC
Created attachment 915949 [details]

Description of problem: dnf group install/remove/upgrade LibreOffice fails with different messages.

Version-Release number of selected component (if applicable):

How reproducible:

Reproduce steps:
1. Install Fedora-Live-Workstation-x86_64 ISO

[root@rawhide chris]# dnf group remove LibreOffice
Error: No relevant match for the specified 'LibreOffice'.
[root@rawhide chris]# dnf group info LibreOffice

Group: LibreOffice
 Description: LibreOffice Productivity Suite
 Mandatory Packages:
 Optional Packages:

[root@rawhide chris]# dnf group upgrade LibreOffice
Error: No relevant match for the specified 'LibreOffice'.
[root@rawhide chris]# dnf group install LibreOffice
Dependencies resolved.
Nothing to do.

Expected results:
Seeing as 'dnf group info' does find information on LibreOffice, it's not correct for dnf to return "no relevant match". Either the group must be upgradable or erasable if already installed, or installable if it isn't. But I can't do any of these three things.

Ideally I'd be able to dnf group erase it, so if part of the problem is that Workstation needs to indicate that it was group installed to begin with, then we should make that happen.

Additional info:
--debugsolver only writes out a debugdata folder for the install sub command. Attaching that.

Comment 1 Ales Kozumplik 2014-07-07 06:28:58 UTC
Thanks, we'll take a look.

Comment 2 Ales Kozumplik 2014-07-30 11:13:01 UTC
This is going to sound surprising but it is the expected behavior: the F20 live CD uses Yum as a backend and DNF can not see its additional package data and thus does not know LibreOffice is considered installed. removal thus fails, as does upgrade. Install does not fail, it just marks the group as installed but sees that the packages are installed. From that moment on, group upgrade of LibreOffice will work as expected in DNF. Removal won't trigger anything again as DNF knows the contained packages were installed by some other (non-group) mechanism and doesn't want to risk breaking the user's setup.

Let's do two things about this bug:

a) tell the user that the group is being marked as installed even when there are no packages to in fact install.
b) add an operation to mark a group *and its packages* installed. The user will have to execute this manually.

Comment 3 Ales Kozumplik 2014-08-04 19:05:36 UTC
The visualization part is supplied in the upstream commit b616f6e.

Comment 4 Ales Kozumplik 2014-08-05 08:19:48 UTC
The issue of package marking is fixed upstream by 13190ee. Note that the final decision was to promote 'unknown' packages to group packages which is safe for dependency autocleaning and resolves the described use case. 

Both the functionalities supplied for this issue will stay experimental for some time to see how they play out in the wild.

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