Description of problem: In some cases, it may not be desirable for the depsolver to make all the decisions for you when it comes to determining which packages are installed to satisfy a dependency. For example, you may have multiple equally weighted sources for a library (from either multiple repositories, or multiple packages in the same repository, or something else). In this case, it's very possible that the depsolver could pick an undesirable option. In scenarios like this, having the ability to ask the user which ones to install can be very useful. I've provided examples under the "Additional info" on how this looks with urpmi. Additionally, for automatic depsolving behavior, it would be great if vendor preference and package preference lists could be set up by users to be used for the purpose of vendor locking/prioritizing or automating specific user choices made here. Version-Release number of selected component (if applicable): dnf-1.1.2-3.fc23 Additional info: Here's some examples of how this functionality works in urpmi on Mageia 5 (GNOME, Core and Nonfree repositories enabled): === Equally weighted providers from multiple repositories === [root@localhost ~]# urpmi bumblebee In order to satisfy the 'bumblebee-bin' dependency, one of the following packages is needed: 1- bumblebee-nouveau-3.2.1-14.20150120.2.mga5.x86_64: Bumblebee configuration files and binaries for nouveau driver (to install) 2- bumblebee-nvidia-3.2.1-14.20150120.2.mga5.nonfree.x86_64: Bumblebee configuration files and binaries for nvidia driver (to install) What is your choice? (1-2) 1 In order to satisfy the 'devel(libstdc++(64bit))' dependency, one of the following packages is needed: 1- libstdc++-devel-4.9.2-4.mga5.x86_64: Header files and libraries for C++ development (to install) 2- libstdc++5-devel-3.3.6-11.mga5.x86_64: Header files and libraries for C++ development (to install) What is your choice? (1-2) 1 To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release") bumblebee 3.2.1 14.20150120.> x86_64 bumblebee-nouveau 3.2.1 14.20150120.> x86_64 dkms 2.0.19 34.mga5 noarch dkms-bbswitch 0.8 6.mga5 noarch dkms-minimal 2.0.19 34.mga5 noarch gcc 4.9.2 4.mga5 x86_64 gcc-cpp 4.9.2 4.mga5 x86_64 glibc-devel 2.20 20.mga5 x86_64 kernel-server-devel-3.19.8-3.> 1 1.mga5 x86_64 kernel-server-devel-latest 3.19.8 3.mga5 x86_64 (recommended) kernel-userspace-headers 3.19.8 3.mga5 x86_64 lib64bsd0 0.7.0 3.mga5 x86_64 lib64mpc3 1.0.2 4.mga5 x86_64 lib64ncurses-devel 5.9 21.mga5 x86_64 lib64primus 0.1 2.20150201.1> x86_64 lib64turbojpeg0 1.3.1 4.mga5 x86_64 (recommended) lib64virtualgl 2.3.3 5.mga5 x86_64 (recommended) libstdc++-devel 4.9.2 4.mga5 x86_64 make 4.0 6.mga5 x86_64 primus 0.1 2.20150201.1> x86_64 primus-nouveau 0.1 2.20150201.1> x86_64 virtualgl 2.3.3 5.mga5 x86_64 (recommended) 120MB of additional disk space will be used. 30MB of packages will be retrieved. Proceed with the installation of the 22 packages? (Y/n) === Equally weighted providers of data for package === [root@localhost ~]# urpmi TiMidity++ In order to satisfy the 'timidity-instruments[== 2]' dependency, one of the following packages is needed: 1- timidity-patch-freepats-20060219-19.mga5.noarch: Patch set for MIDI audio synthesis (to install) 2- timidity-patch-fluid-3.1-11.mga5.noarch: Pro-quality General Midi soundfont in GUS patch format (to install) 3- timidity-patch-gravis-1.0-34.mga5.noarch: Instruments for the timidity midi->wave converter/player (to install) What is your choice? (1-3) 1 To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release") TiMidity++ 2.14.0 6.mga5 x86_64 timidity-patch-freepats 20060219 19.mga5 noarch 33MB of additional disk space will be used. 24MB of packages will be retrieved. Proceed with the installation of the 2 packages? (Y/n) === Equally weighted providers of libraries === [root@localhost ~]# urpmi git In order to satisfy the 'libapr-1.so.0()(64bit)' dependency, one of the following packages is needed: 1- lib64apr1_0-1.5.1-3.mga5.x86_64: Apache Portable Runtime library (to install) 2- lib64unimrcp-deps-1.1.2-6.mga5.x86_64: UniMRCP depends Stack shared librarries (to install) What is your choice? (1-2) 1 In order to satisfy the 'libaprutil-1.so.0()(64bit)' dependency, one of the following packages is needed: 1- lib64apr-util1_0-1.5.4-4.mga5.x86_64: Apache Portable Runtime Utility library (to install) 2- lib64unimrcp-deps-1.1.2-6.mga5.x86_64: UniMRCP depends Stack shared librarries (to install) What is your choice? (1-2) 1 To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release") cvs 1.12.13 25.mga5 x86_64 (recommended) cvsps 2.2b1 6.mga5 x86_64 (recommended) lib64apr-util1_0 1.5.4 4.mga5 x86_64 lib64apr1_0 1.5.1 3.mga5 x86_64 lib64serf1 1.3.8 1.mga5 x86_64 perl-Authen-SASL 2.160.0 5.mga5 noarch (recommended) perl-Digest-HMAC 1.30.0 6.mga5 noarch (recommended) perl-Digest-SHA1 2.130.0 15.mga5 x86_64 (recommended) perl-Error 0.170.220 4.mga5 noarch perl-MIME-Base64 3.140.0 7.mga5 x86_64 (recommended) perl-YAML 1.110.0 5.mga5 noarch (medium "Core Updates") git 2.3.8 1.mga5 x86_64 git-arch 2.3.8 1.mga5 x86_64 (recommended) git-core 2.3.8 1.mga5 x86_64 git-core-oldies 2.3.8 1.mga5 x86_64 (recommended) git-cvs 2.3.8 1.mga5 x86_64 (recommended) git-email 2.3.8 1.mga5 x86_64 git-prompt 2.3.8 1.mga5 x86_64 (recommended) git-svn 2.3.8 1.mga5 x86_64 gitk 2.3.8 1.mga5 x86_64 (recommended) lib64svn0 1.8.14 1.mga5 x86_64 perl-Git 2.3.8 1.mga5 x86_64 perl-SVN 1.8.14 1.mga5 x86_64 subversion 1.8.14 1.mga5 x86_64 46MB of additional disk space will be used. 9.6MB of packages will be retrieved. Proceed with the installation of the 24 packages? (Y/n) === Equally weighted packages with the same virtual Provides === [root@localhost ~]# urpmi dm In order to satisfy the 'xdm|lxdm|lightdm|kdm|gdm|lightdm' dependency, one of the following packages is needed: 1- kdm-4.11.16-5.mga5.x86_64: KDE Desktop Login Manager (to install) 2- lxdm-0.5.0-3.mga5.x86_64: GUI login manager for LXDE (to install) 3- lightdm-1.14.2-1.mga5.x86_64: The Light Display Manager (to install) What is your choice? (1-3) 3 To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release") light-locker 1.6.0 1.mga5 x86_64 (recommended) (medium "Core Updates") lib64lightdm-gobject1_0 1.14.2 1.mga5 x86_64 lightdm 1.14.2 1.mga5 x86_64 lightdm-gtk-greeter-common 2.0.1 1.mga5 noarch lightdm-gtk3-greeter 2.0.1 1.mga5 x86_64 1.7MB of additional disk space will be used. 534KB of packages will be retrieved. Proceed with the installation of the 5 packages? (Y/n)
This would also be useful with the new boolean dependency logic support in RPM, as the user would be queried on the correct choice instead of it picking one.
The feature could be useful but I have to close this. We would need the libsolv to provide provides selection callback in order to accomplish this. It could be done by a lots of queries without usage of libsolv depsolver - which is a way backwards. Feel free to reopen once it's possible. related: https://github.com/openSUSE/libsolv/issues/66 and bug 1192182
So, I made a feature request to libsolv about it[0], and it turns out that it is possible, provided the user query happens after all the chains have been retrieved. So instead of happening *during* the depsolve, it happens after the depsolve, where users can be queried to resolve "unresolvable" states. Having it happen at the end is totally fine, since the end result is still the same. [0]: https://github.com/openSUSE/libsolv/issues/107
It's been a couple of months since I filed this issue and reopened it. Has there been any progress on it? It would be extraordinarily useful to have for the purpose of resolving the provider cases I noted earlier, as well as "vendor" changes (package provided by one repository being replaced by one provided by another), and resolving boolean dependencies using user input where appropriate.
It seems that it is indeed possible to set package preferences for DNF by having a package with Suggests, so I've implemented that in Mageia as "mageia-repos-pkgprefs" package. However, a user in Mageia has encountered issues related to not being able to select from equally valid providers of a capability. As I mentioned earlier, it should be possible after the depsolve is complete by libsolv, so hawkey/libhif should appropriately handle this and return a query to the user to make a decision. I've referenced the Mageia bug in the "See Also" since the Mageia bug tracker (which is a Bugzilla instance) doesn't seem to be available from the external bug trackers list.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.