Bug 1266761

Summary: [RFE] Add option to allow users to select from multiple providers of a Requirement at depsolve time
Product: [Fedora] Fedora Reporter: Neal Gompa <ngompa13>
Component: dnfAssignee: rpm-software-management
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: low    
Version: rawhideCC: carl, Frodox, gholms, jzeleny, packaging-team-maint, tim.lauridsen, vmukhame
Target Milestone: ---Keywords: FutureFeature, Reopened, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-10-06 14:59:01 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:
Embargoed:
Bug Depends On: 1533878, 1148627, 1549851    
Bug Blocks:    

Description Neal Gompa 2015-09-27 13:58:33 UTC
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)

Comment 1 Neal Gompa 2015-09-29 14:03:22 UTC
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.

Comment 2 Honza Silhan 2015-10-06 14:59:01 UTC
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

Comment 3 Neal Gompa 2015-10-09 13:27:21 UTC
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

Comment 4 Neal Gompa 2015-12-17 06:18:48 UTC
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.

Comment 5 Neal Gompa 2016-04-30 22:50:06 UTC
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.

Comment 6 Fedora Admin XMLRPC Client 2016-07-08 09:38:16 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 7 Fedora End Of Life 2016-11-24 12:37:50 UTC
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.