Bug 1327258

Summary: dnf install gnome-terminal FOOBAR: does not install gnome-terminal
Product: [Fedora] Fedora Reporter: Jan Kratochvil <jan.kratochvil>
Component: dnfAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: jan.kratochvil, jsilhan, mluscon, mmraka, packaging-team-maint, pnemade, vmukhame
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-04-26 08:09:41 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:

Description Jan Kratochvil 2016-04-14 15:23:25 UTC
Description of problem:
If just one package of the list does not exist nothing happens.  But I may want to install the other ones.

Version-Release number of selected component (if applicable):
dnf-1.1.8-1.fc25.noarch

How reproducible:
Always.

Steps to Reproduce:
dnf install gnome-terminal FOOBAR

Actual results:
Last metadata expiration check: 2:31:47 ago on Thu Apr 14 14:47:37 2016.
No package FOOBAR available.
Error: Unable to find a match.

Expected results:
No package FOOBAR available.
Installing:
  gnome-terminal-3.20.1-1.fc25.x86_64
OR:
No package FOOBAR available.
To install the remaining specified packages use: --ignore-missing-packages

Additional info:
Maybe some --ignore-missing-packages exists but I do not see it in dnf install --help and also 'dnf install' could suggest it when some of its arguments did exist + they were not installed.

Comment 1 Michael Mráka 2016-04-18 12:15:20 UTC
dnf install --setopt strict=false gnome-terminal FOOBAR

is what you are looking for.

Comment 2 Jan Kratochvil 2016-04-18 13:25:59 UTC
Yes, thanks.

I do not know why it is not the default.  At least yum (RHEL-7) behaved that way and this is what I expect as a user.

But if strict=true needs to be the default please suggest '--setopt strict=false' while printing the final error message (if some of dnf install arguments did exist + they were not installed).

I had to do instead: for i in `cat ~/INSTALL`;do dnf install $i;done

Comment 3 Michael Mráka 2016-04-25 13:15:43 UTC
It isn't a default because dnf prefers consistent behaviour across commands. So both
 dnf install A
 dnf install A B
fail if A can't be installed,
For people who'd like to stick with yum's behaviour there's strict=false option.

Comment 4 Jan Kratochvil 2016-04-25 14:11:29 UTC
(In reply to Michael Mráka from comment #3)
> It isn't a default because dnf prefers consistent behaviour across commands.

One could say consistency means that if B is installable and B is requested then B should get installed.  But sure that's DNF's decision.

(In reply to Jan Kratochvil from comment #2)
> But if strict=true needs to be the default please suggest '--setopt
> strict=false' while printing the final error message (if some of dnf install
> arguments did exist + they were not installed).

This possible fix has not been addressed.  If it is not going to be addressed then the resolution should be CLOSED-WONTFIX (not CLOSED-NOTABUG).