Created attachment 915949 [details] debugdata.tgz Description of problem: dnf group install/remove/upgrade LibreOffice fails with different messages. Version-Release number of selected component (if applicable): dnf-0.5.3-1.fc21.noarch hawkey-0.4.17-1.fc21.x86_64 libsolv-0.6.1-2.git6d968f1.fc21.x86_64 How reproducible: Always 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: libreoffice-calc libreoffice-draw libreoffice-emailmerge libreoffice-graphicfilter libreoffice-impress libreoffice-math libreoffice-writer Optional Packages: libreoffice-base libreoffice-pyuno [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.
Thanks, we'll take a look.
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.
The visualization part is supplied in the upstream commit b616f6e.
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.