Bug 995459 - conflicting requests when trying to install locally available packages
Summary: conflicting requests when trying to install locally available packages
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 19
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Ales Kozumplik
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-08-09 12:29 UTC by Richard Marko
Modified: 2016-05-30 13:09 UTC (History)
6 users (show)

Clone Of:
Last Closed: 2013-10-09 14:21:21 UTC

Attachments (Terms of Use)
debugdata from --debugsolver (8.48 MB, application/x-gzip)
2013-08-09 12:29 UTC, Richard Marko
no flags Details
solver.result (2.54 KB, text/plain)
2013-09-27 12:30 UTC, Richard Marko
no flags Details

Description Richard Marko 2013-08-09 12:29:23 UTC
Created attachment 784829 [details]
debugdata from --debugsolver

Description of problem:
dnf install /home/rmarko/work/libreport/x86_64/*rpm results in following:

Setting up Install Process
Resolving Dependencies
--> Starting dependency resolution
--> Finished dependency resolution
Error: conflicting requests

Version-Release number of selected component (if applicable):

How reproducible:

Comment 1 Ales Kozumplik 2013-08-09 13:38:57 UTC
(looking into this, debugging with Richard online)

Comment 2 Ales Kozumplik 2013-08-09 14:25:40 UTC
It looks like we are giving libsolv a bogus job that both excludes and tries to install libreport-web-devel. I can not reproduce this locally and we confirmed that no packages are excluded by your DNF configuration.

I'd like to find out how precisely we create the bogus job. For that I've built a special hawkey version that checks what packages we exclude. Can you please try this by upgrading your hawkey to:


Then please rerun the job and attach /var/cache/dnf/x86_64/19/hawkey.log to this?

Thank you.

Comment 3 Richard Marko 2013-08-13 10:35:35 UTC
It seems that I'm no longer able to reproduce this.

Comment 4 Ales Kozumplik 2013-08-13 10:37:24 UTC
I'll keep this open for now anyway, I've found that when we exclude packages and then try to install them we get similar weird error that can be hard to track down for the user.

Comment 5 Ales Kozumplik 2013-08-13 12:55:02 UTC
For the record, this is is a reproducer:

dnf -x 'libnm-*' install libnm-gtk-devel
Setting up Install Process
Resolving dependencies
--> Starting dependency resolution
--> Finished dependency resolution
Error: conflicting requests

Comment 6 Ales Kozumplik 2013-08-13 13:20:47 UTC
Related: bug 884617 where it was originally proposed to employ SOLVER_LOCK.

Comment 7 Ales Kozumplik 2013-08-13 14:29:25 UTC

Sorry for this being a bit longer, please bear with me.

this is an interesting case. Recall from the bug 884617 where we
decided to put SOLVER_LOCK into the job with all packages
matching the exlcude name.

Suppose the following:

repo system 0 testtags <inline>
#>=Ver: 2.0
#>=Pkg: c 1 1 x86_64
repo available 0 testtags <inline>
#>=Pkg: d 2 1 x86_64
repo available2 0 testtags <inline>
#>=Pkg: d 2 2 x86_64

system x86_64 rpm system

job install name d
job lock pkg d-2-2.x86_64@available2

(IOW, the user has excluded all 'd*' from the repo 'available2'
and wants to isntall a 'd'). In this case, the job has a solution
and I can go ahead and let the solver handle it. However, if
there wasn't for d@available this would cause an
error ('conflicting requests').

First I was thinking I should be able to tell the user, ahead of
resolving, something like 'you are excluding all your install
candidates, error.', but to determine ahead of running the job
whether or not the excludes are reasonable means quite extra work
to perform and duplicates what libsolv can do already (i.e. a bad

Alternatively I am thniking letting the job run and fail and then
tell the user, but I will somehow have to translate the following
back into the 'language of excludes' the user will understand:

+problem 9c014596 info conflicting requests
+problem 9c014596 solution a7fe0a1d deljob lock pkg d-2-2.x86_64@available2
+problem 9c014596 solution e1b58e11 deljob install name d

Is that the right thing to do here?

I'm also thinking again that implementing the excludes by
disabling them from the pool in some way would work around this
nicely too (i.e. in case the job doesn't make sense becauase all
providers are excluded we'd get 'nothing provides d').

Comment 8 Richard Marko 2013-09-27 12:30:08 UTC
Created attachment 803928 [details]

Hitting this again while trying to install packages from local folder.

dnf install *.rpm 
results in 
Error: conflicting requests

Comment 9 Michael Schröder 2013-09-27 13:32:54 UTC
Ales, if yum allows the installation of excluded packages, dnf should probably allow it as well (to keep the confusion about both tools minimal).

So first we have to find out what the exact semantics of yum's exclude handling are. Say, if I ask yum to "install a package providing foo", and both bar and baz provide foo, but both bar and baz are excluded, what does yum do?

Or is exclude only processed for update jobs?

Comment 10 Ales Kozumplik 2013-09-27 14:09:14 UTC
This is what yum documentation says:

exclude List of packages to exclude from all repositories, so yum works as if that package was never in the  repositories..  This  should  be a space separated list.  This is commonly used so a package isn't upgraded or installed accidentally, but can be used to remove packages in any way that "yum list"  will show packages.  Shell globs using wildcards (eg. * and ?) are allowed.

So it's probably not about provides, just packages. I tried this with yum:

yum install -x python-xmpp --assumeno python-xmpp

-> Error: Nothing to do

yum install -x python-xmpp --assumeno ./python-xmpp-0.5.0-0.7.rc1.fc19.noarch.rpm

-> Error: Nothing to do

Both results are more or less what I would expect from the documentation.

Comment 11 Michael Schröder 2013-09-27 14:23:31 UTC
Yes, but I meant it the other way round: yum install <some_provides>, where some_provides is provides by a excluded package.

But in your first example, did yum silently ignore your install command? I would expect a "No package python-xmpp available" error message according to the documentation.

Comment 12 Ales Kozumplik 2013-09-27 14:27:54 UTC
Does this answer your first question?

[root@caws ~]# rpm -qp --provides python-xmpp-0.5.0-0.7.rc1.fc19.noarch.rpm 
python-xmpp = 0.5.0-0.7.rc1.fc19
xmpppy = 0.5.0-0.7.rc1.fc19
[root@caws ~]# yum install -x python-xmpp xmpppy
Loaded plugins: langpacks, refresh-packagekit
No package xmpppy available.
Error: Nothing to do

In the second case, yes, I omitted the following line from pasting:

No package python-xmpp available.

Comment 13 Michael Schröder 2013-09-27 14:48:10 UTC
So it simply removes all matching packages from the repos? If you want that for dnf, you can easily implement it. Either by deleting the matching packages from the repos (skipping @System, I guess), or by using the "considered" map from the pool.

Note that you have to call createwhatprovides() after that to re-create the provides index.

I'd prefer a different solution, though, which gives the user some feedback that  the error happened because a package was excluded.

Basically, dnf exiting with an error is consistent with yum, it's just the error message that needs to be improved. You can do some introspection to get a list of jobs in the "conflicting jobs" case and print a different error if one of the jobs is a job generated by an "excludes".

Comment 14 Ales Kozumplik 2013-09-27 14:58:52 UTC
Thanks Michael, I'll try the second approach first and see how far the introspection gets me (since we can exclude globs etc.).

Comment 15 Ales Kozumplik 2013-09-30 10:07:27 UTC
Fixed in hawkey by d21f74b, thanks for sending the introspection patch Michael. The fix will be included in hawkey-0.4.2.

Richard, while the fix above is to a legit bug, there's some little doubt in me that this will help you (because you've said two times now that you don't use any excludes). If that's the case then hawkey must be doing something wrong when building the job queue. Please open a new bugzilla in such case and attach the debugdata/ directory obtained by running dnf with --debugsolver. Also a link to the repo you are working with would be of great help. Thank you!

Comment 16 Fedora Update System 2013-10-01 13:52:22 UTC
dnf-0.4.2-1.gitc1716d7.fc20 has been submitted as an update for Fedora 20.

Comment 17 Fedora Update System 2013-10-02 06:49:46 UTC
Package dnf-0.4.2-1.gitc1716d7.fc20, librepo-1.2.0-1.fc20, hawkey-0.4.2-1.git4c51f65.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dnf-0.4.2-1.gitc1716d7.fc20 librepo-1.2.0-1.fc20 hawkey-0.4.2-1.git4c51f65.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 18 Fedora Update System 2013-10-09 14:21:21 UTC
dnf-0.4.2-1.gitc1716d7.fc20, librepo-1.2.0-1.fc20, hawkey-0.4.2-1.git4c51f65.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 19 Michael Schröder 2016-05-30 13:09:02 UTC
(clearing needinfo)

Note You need to log in before you can comment on or make changes to this bug.