Bug 1464249

interesting....

This problem is surprisingly caused due to that in dnf-1.1 where implementation of globs broken. They where applicable only to name, and other possibilities were impossible. In dnf-2.5, globs can be used everywhere. Unfortunately globs can match packages differently from expectation, but request can be altered.

Your problem can be solved:

sudo dnf install imagefactory-plugins* --exclude imagefactory-plugins --assumeno
sudo dnf install-n imagefactory-plugins-* --assumeno

> sudo dnf install-n imagefactory-plugins-* --assumeno

what is install-n ?

install-n means that all of the arguments are package names (parser will not try other forms)

install-na means that you provide name.arch

install-nevra means that you provide full nevra of packages

This was implemented just for cases like you end up, where you know what you provide and you reduce possible options for parser (globs often provide more possible solutions).

Your argument imagefactory-plugins-* could be recognized as name-version or name.
name-version form is tested first and if it is valid (and it was because there is imagefactory-plugins package) no further options are tested.

Hope that it helped.

So, is there an 'update-n' command? (I still like the old `yum update` command, it's match result is not confusing)


# LANG=C dnf update --enablerepo updates-testing --enablerepo rpmfusion-free-updates-testing
====================================================================================================
 Package                   Arch   Version                      Repository                      Size
====================================================================================================
Upgrading:
 ............
 libva                     i686   1.8.3-1.fc26                 updates-testing                 85 k
 libva                     x86_64 1.8.3-1.fc26                 updates-testing                 82 k
 libva-intel-driver        i686   1.8.3-1.fc26                 rpmfusion-free-updates-testing 740 k
 libva-intel-driver        x86_64 1.8.3-1.fc26                 rpmfusion-free-updates-testing 714 k
 ............



# LANG=C dnf update --enablerepo updates-testing --enablerepo rpmfusion-free-updates-testing  libva-*
Last metadata expiration check: 5:09:00 ago on Mon Jul 17 10:25:27 2017.
Dependencies resolved.
====================================================================================================
 Package           Arch               Version                     Repository                   Size
====================================================================================================
Upgrading:
 libva             i686               1.8.3-1.fc26                updates-testing              85 k
 libva             x86_64             1.8.3-1.fc26                updates-testing              82 k

Transaction Summary
====================================================================================================
Upgrade  2 Packages

Total download size: 167 k
Is this ok [y/N]:



# LANG=C dnf update-n --enablerepo updates-testing --enablerepo rpmfusion-free-updates-testing  libva-*
No such command: update-n. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(update-n)'"

You discovered good point, that only install, remove, autoremove commands use -n, -na, and -nevra suffix (this is exactly like in yum). We should make dnf more consistent.

PS: My question is why you use libva-*, imagefactory-plugins-* arguments, instead of "libva*", "imagefactory-plugins*"? In all cases arguments without "-" will provide expected result.

(In reply to Jaroslav Mracek from comment #6)
> PS: My question is why you use libva-*, imagefactory-plugins-* arguments,
> instead of "libva*", "imagefactory-plugins*"? In all cases arguments without
> "-" will provide expected result.

When using yum, sometimes I just want to use `yum update` to check the current version number of multiple packages, less match result would be better for me. Now yum is deprecated, but old habit remains :D

Another reason is just I don't want to update package whose name doesn't contains '-', such as update
  - 'mariadb-server' but no 'mariadb' (which should be named as 'mariadb-client',
  - 'grub2-efi' but no 'grub2',
  - 'libva-intel-driver' but no 'libva',
  - 'freetype-freeworld' but no 'freetype'
  something like that ...

I create a PR: https://github.com/rpm-software-management/libdnf/pull/311 that should solve the original issue. Please if anyone can test it, I will be very happy.

libdnf-0.9.3-1.fc26 dnf-plugins-core-2.1.3-1.fc26 dnf-2.6.2-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-6f4c06b2d7

so with the PR does the functionality go back to how it was in f25? Or is it some new behavior that's meant to workaround? An explanation of the behavior would be useful in this BZ.

The behavior should be like in fedora 25.

dnf-2.6.2-1.fc26, dnf-plugins-core-2.1.3-1.fc26, libdnf-0.9.3-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-6f4c06b2d7

dnf-2.6.2-1.fc26, dnf-plugins-core-2.1.3-1.fc26, libdnf-0.9.3-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.