Bug 1460424

Summary: dnf ignoring obsoletes version bound?
Product: [Fedora] Fedora Reporter: Jens Petersen <petersen>
Component: dnfAssignee: rpm-software-management
Status: CLOSED CANTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 26CC: dmach, jmracek, packaging-team-maint, petersen, rpm-software-management, vmukhame
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-07-27 15:21:21 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:
Attachments:
Description Flags
debugdata.tar none

Description Jens Petersen 2017-06-10 09:48:59 UTC 
Description of problem:
git-annex no longer builds for F26+.
ghc-obsoletes currently obsoletes the older git-annex version which no longer builds.
I have a copr repo with a newer version of git-annex.
DNF seems unable to install git-annex even though the version is newer than the obsoletes.

Is this an known issue or expected behaviour?

How reproducible:
100%

Steps to Reproduce:
1. dnf install git-annex
2. dnf copr enable petersen/git-annex

Actual results:
1. tries to install ghc-obsoletes
2. tries to install ghc-obsoletes even though version is newer than obsoletes

Expected results:
2. install git-annex from copr

Additional info:
A workaround is to install "git-annex-<VERSION>".
Comment 1 Igor Gnatenko 2017-06-14 11:28:40 UTC 
Please, run it with --debugsolver and attach debugdata directory.. This will help me to understand what's going on.
Comment 2 Jens Petersen 2017-06-22 02:22:00 UTC 
Created attachment 1290422 [details]
debugdata.tar

Sorry for the delay, here you go.
Comment 3 Igor Gnatenko 2017-07-01 17:37:51 UTC 
Looks like there is a bug in libsolv's `oneof` implementation, but that's not really critical since primary bug is in libdnf/dnf:

job install oneof ghc-obsoletes-1.6.19-2.fc26.x86_64@@System git-annex-6.20170519-1.fc26.x86_64@petersen-git-annex ghc-obsoletes-1.6.19-2.fc26.x86_64@updates-testing ghc-obsoletes-1.6.19-2.fc26.x86_64@fedora git-annex-5.20140717-13.fc26.x86_64@fedora [setevr,setarch]

Basically, dnf doesn't handle those obsoletes properly.

Jaroslav is the best person to deal with this problem.
Comment 4 Igor Gnatenko 2017-07-17 14:10:42 UTC 
> Jaroslav Mracek 2017-07-17 16:07:41 CEST
> Keywords: Triaged
> Assignee: jmracek → rpm-software-management.org

Please, explain.
Comment 5 Jaroslav Mracek 2017-07-27 15:21:21 UTC 
Just to explain the logic here. If you use only name of packages, dns suggests that you want to install on of following possibilities:
1 Packages with that package name
2. Packages that obsoletes the packages from first point.

If you add additional information like version, arch ... it only installs what was requested without obsoletes. 

In your case ghc-obsoletes obsoletes git-annex-5.20140717-13.fc26.x86_64@fedora, therefore solver is satisfied with installed ghc-obsoletes (this is correct behavior). It is true that there is one additional package git-annex-6.20170519-1.fc26.x86_64@petersen-git-annex that is not obsoleted, but it is difficult in such complicate case to exactly guess, what exactly user prefer. I believe that if there will be no ghc-obsoletes on your system, the primary option for solver would be latest git-annex.

I don't think, that we can change the behavior, because obsoletes are often use to remove unsupported packages from the system, and I see that this workaround is not nice at all. If we will not add obsoletes into install transaction, there will be users but mostly devels and maintainers that start to scream about.

I am really sorry, but there is no other option.