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): dnf-1.1.4-2.fc23.noarch How reproducible: Fully repeatable
Please could you provide additional information. 1. List of duplicated packages 2. Output from package-cleanup Thanks a lot
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.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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.
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.
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. Example: TestN-1.0.0-1.1515.g4g4d5f4g5fd4g6.fc24.x86_64 Name = TestN Version = 1.0.0 Release = 1.1515.g4g4d5f4g5fd4g6.fc24 Arch = x86_64
In your example Jaroslav, if I had just upgraded to F25 I would expect the package to get upgraded to: TestN-1.0.0-1.1515.g4g4d5f4g5fd4g6.fc25.x86_64 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.
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. Jaroslav
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.