Bug 995459

(looking into this, debugging with Richard online)

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:

http://akozumpl.fedorapeople.org/hawkey-0.3.16-90.gitd323bda.fc19.x86_64.rpm
http://akozumpl.fedorapeople.org/python-hawkey-0.3.16-90.gitd323bda.fc19.x86_64.rpm

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

Thank you.

It seems that I'm no longer able to reproduce this.

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.

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

Related: bug 884617 where it was originally proposed to employ SOLVER_LOCK.

Michael,

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
sign).

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').

Created attachment 803928 [details]
solver.result

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

dnf install *.rpm 
results in 
Error: conflicting requests

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?

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.

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.

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.

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".

Thanks Michael, I'll try the second approach first and see how far the introspection gets me (since we can exclude globs etc.).

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!

dnf-0.4.2-1.gitc1716d7.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/dnf-0.4.2-1.gitc1716d7.fc20

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:
https://admin.fedoraproject.org/updates/FEDORA-2013-18123/librepo-1.2.0-1.fc20,hawkey-0.4.2-1.git4c51f65.fc20,dnf-0.4.2-1.gitc1716d7.fc20
then log in and leave karma (feedback).

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.

(clearing needinfo)