Bug 1287785 - dnf does not differentiate between OS releases if the version and release are the same
dnf does not differentiate between OS releases if the version and release are...
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
Unspecified Unspecified
low Severity unspecified
: ---
: ---
Assigned To: rpm-software-management
Fedora Extras Quality Assurance
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2015-12-02 11:42 EST by Andrew Meredith
Modified: 2017-05-15 08:37 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-05-12 13:20:16 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)

  None (edit)
Description Andrew Meredith 2015-12-02 11:42:56 EST
Description of problem:

This is mainly an upgrade issue, but the cause seems to be in dnf itself. Once the upgrade (in this case F22 -> F23) is done, if the tool "package-cleanup --orphans" is used to track out of distro packages, the bulk of the returns are for packages with the same name, version & release, but from previous distro versions. While for the most part this will work, if there is a distro version based difference between the otherwise identical packages, there will be an issue.

NB Even the distro-sync plugin can't tell these packages apart.

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


How reproducible:

Fully repeatable
Comment 1 Jaroslav Mracek 2015-12-08 09:48:04 EST
Please could you provide additional information.

1. List of duplicated packages

2. Output from package-cleanup

Thanks a lot
Comment 2 Andrew Meredith 2015-12-08 09:55:54 EST
1 - There are no duplicated packages.

The packages at issue are simply not upgraded from the previous distro because they are otherwise identical. ie the name, version and release are the same, but they are tagged fc22, not fc23.

2 - I have done the reconciliation now, so there is nothing of use in the package-cleanup output any more.

Please note that this is not a new issue, but was one that I had hoped would be sorted out by this new regime of distro upgrades. Every Fedora upgrade I have done since the FC1 -> FC2 had this same issue, whatever mechanism I used for upgrade. In fact it existed in RHL before it. Package-cleanup seems to be the only tool that can differentiate between them.
Comment 3 Fedora Admin XMLRPC Client 2016-07-08 05:36:56 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 4 Fedora End Of Life 2016-11-24 08:55:52 EST
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.
Comment 5 Jaroslav Mracek 2016-11-25 10:11:19 EST
It looks like that if TestN-1.0.0-1.fc24.x86_64 is present on system and TestN-1.0.0-1.fc25.x86_64 available, ```dnf upgrade``` do upgrade to TestN-1.0.0-1.fc25.x86_64.

Tested with dnf-1.1.10-3.fc25.noarch and dnf-2.0 with same result. 
I know that this is different story, but information can be helpful.
Comment 6 Jaroslav Mracek 2017-05-12 13:20:16 EDT
I would like to point out that distro tag is part of the release and dnf handle that as a string. The problems about compatibility here is mostly problem of packaging, especially requirements of the package. Personally I don't think that parsing release and taking some meaning from it is good approach. The important part is what is in spec, like requires, provides, conflict ... . Additionally important information is presence in distro specific repository, therefore your request is mostly packaging problem or distributional problem, therefore it has to be solved on those levels. 


Name = TestN
Version = 1.0.0
Release = 1.1515.g4g4d5f4g5fd4g6.fc24
Arch = x86_64
Comment 7 Andrew Meredith 2017-05-15 06:50:04 EDT
In your example Jaroslav, if I had just upgraded to F25 I would expect the package to get upgraded to:

Name = TestN
Version = 1.0.0
Release = 1.1515.g4g4d5f4g5fd4g6.fc25
Arch = x86_64

dnf is able to see that the release version is different and should download the f25 version and install it. This isn't a packaging or naming issue, the package is named for the Fedora release it is built for, the issue is that dnf doesn't upgrade it despite it being a different "higher" release than the one installed.
Comment 8 Jaroslav Mracek 2017-05-15 07:53:45 EDT
Thanks for the report. Please if you will find an example when dnf doesn't recognize update from something like TestN-1.0.0-1.1515.g4g4d5f4g5fd4g6.fc24.x86_64 to 
TestN-1.0.0-1.1515.g4g4d5f4g5fd4g6.fc25.x86_64, please don't hesitate reopen the bug report, because it will be an issue. The higher version should be installable.

Comment 9 Andrew Meredith 2017-05-15 08:37:03 EDT
Packages have been left behind at the previous release level after every Fedora upgrade I have ever done; be that with yum or dnf. I am given to understand that this is a long standing issue and that there is a general unwillingness to tackle it.

Hence the premature, unrequested closure of this ticket I assume.

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