Bug 1460424 - dnf ignoring obsoletes version bound?
dnf ignoring obsoletes version bound?
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: rpm-software-management
Fedora Extras Quality Assurance
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2017-06-10 05:48 EDT by Jens Petersen
Modified: 2017-07-27 11:21 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-07-27 11:21:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
debugdata.tar (8.43 MB, application/x-tar)
2017-06-21 22:22 EDT, Jens Petersen
no flags Details

  None (edit)
Description Jens Petersen 2017-06-10 05:48:59 EDT
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:

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 07:28:40 EDT
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-21 22:22 EDT
Created attachment 1290422 [details]

Sorry for the delay, here you go.
Comment 3 Igor Gnatenko 2017-07-01 13:37:51 EDT
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 10:10:42 EDT
> Jaroslav Mracek 2017-07-17 16:07:41 CEST
> Keywords: Triaged
> Assignee: jmracek@redhat.comrpm-software-management@lists.fedoraproject.org

Please, explain.
Comment 5 Jaroslav Mracek 2017-07-27 11:21:21 EDT
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.

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