Description of problem: As it seems dnf doesn;t handle obsoletes/provides correctly or at least different from yum: Version-Release number of selected component (if applicable): dnf-0.4.20-1.fc20.noarch How reproducible: 100% Steps to Reproduce: 1. try to install libbluray-java 2. it fails Actual results: DNF: [root@dhcp130-197 ~]# dnf install libbluray-java Resolving dependencies --> Starting dependency resolution --> Finished dependency resolution Error: package libbluray-java-0.4.0-1.fc20.x86_64 requires libbluray(x86-64) = 0.4.0-1.fc20, but none of the providers can be installed YUM: [root@dhcp130-197 ~]# yum install libbluray-java Loaded plugins: langpacks, refresh-packagekit Package libbluray-java is obsoleted by libbluray-bdj, trying to install libbluray-bdj-0.5.0-2.fc20.x86_64 instead Resolving Dependencies --> Running transaction check ---> Package libbluray-bdj.x86_64 0:0.5.0-2.fc20 will be installed --> Finished Dependency Resolution Dependencies Resolved <cutted out> Total download size: 480 k Installed size: 560 k Is this ok [y/d/N]: Expected results: libbluray-java is obviously obsoleted by libbluray-bdj, but dnf fails to resolve it.
Hello Jiri, can you attach the solver debug data [1]? Many thanks. [1] http://dnf.baseurl.org/2013/11/25/reporting-depsolving-bugs/
http://jmoskovc.fedorapeople.org/debugdata.zip
The debugdata pretty much reflect what Jiri described in comment 0: libbluray-java can not be installed and is obsoleted by libbluray-bdj. Yum automatically uses libbluray-bdj instead, this is triggered by conf.obsoletes which is documented as follows: obsoletes This option only has affect during an update. It enables yum's obsoletes processing logic. Useful when doing distribution level upgrades. See also the yum upgrade command documentation for more details (yum(8)). Default is `true'. Command-line option: --obsoletes Our options are either to act the same or to just document this as a discrepancy from badly documented behavior in Yum (notice the doc talks about updates only). I'd prefer the latter. Michael, what do you think and can libsolv emulate something similar to the former? By the way, DNF/libsolv would of course do the right thing if libbluray-java was already installed and the user chose to do an upgrade or distupgrade.
Hm, OTOH, I think hawkey builds the goal wrong: job install name libbluray-java instead of job install provides libbluray-java . Back to the lab.
I don't think hawkey builds the goal wrong. Moreover, I'd argue that the yum behavior is wrong. If the user asks for a specific package name it should not install something else. (And please to not switch to "job install provides", as that does not take obsoletes into account.) As for "can libsolv do the same?": yes, of course. You can create any job you like by specifying a set of package ids instead of a string. So you can check if there is a package with an obsoletes and if that's the case switch over to the set method. Note that just checking obsoletes is probably not enough, you must also take repo priorities into account (I would not be surprised if yum does not do that). But anyway, my personal preference is that you should not change anything and just document this as dnf being different to yum.
Fair enough, thanks for your take. 'job install provides' would work in this specific case because libbluray-bdj provides libbluray-java. I thought that was the norm when obsoleting but then I found http://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages#Caveats That, together with your negative stance towards the behavior of Yum, makes me rethink this into just documenting it as a quirk we are not going to emulate.
Agree with Michael, that if the user ask to install X, dnf should not install Y. Don't now if it possible to give the user a better error message Error: package libbluray-java-0.4.0-1.fc20.x86_64 requires libbluray(x86-64) = 0.4.0-1.fc20, but none of the providers can be installed Is not very userfriendly, yum says Package libbluray-java is obsoleted by libbluray-bdj.... this is more user friendly :)
Documented the difference from Yum upstream. At some point we might consider better error messages but it is a different (and much more complex) topic.
dnf-plugins-core-0.0.8-2.fc20, libsolv-0.6.1-1.git6d968f1.fc20, hawkey-0.4.16-1.fc20, dnf-0.5.2-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/libsolv-0.6.1-1.git6d968f1.fc20,hawkey-0.4.16-1.fc20,dnf-0.5.2-1.fc20,dnf-plugins-core-0.0.8-2.fc20
Package dnf-plugins-core-0.0.8-2.fc20, libsolv-0.6.1-1.git6d968f1.fc20, hawkey-0.4.16-1.fc20, dnf-0.5.2-1.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-plugins-core-0.0.8-2.fc20 libsolv-0.6.1-1.git6d968f1.fc20 hawkey-0.4.16-1.fc20 dnf-0.5.2-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-6789/libsolv-0.6.1-1.git6d968f1.fc20,hawkey-0.4.16-1.fc20,dnf-0.5.2-1.fc20,dnf-plugins-core-0.0.8-2.fc20 then log in and leave karma (feedback).
IMHO, it makes no sense whatsoever to install an obsolete package, that: 1. is entirely unmaintained, because it is replaced by something else, 2. can have broken dependencies, as in the initial post in this bug report, and, 3. will get replaced by the next update operation.
dnf-plugins-core-0.0.8-2.fc20, libsolv-0.6.1-1.git6d968f1.fc20, hawkey-0.4.16-1.fc20, dnf-0.5.2-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
I just ended up confused by this in bug #1200088. I agree that switching out what gets installed is a little confusing, but I think the alternative (i.e. the current behavior) is worse, basically for the same reasons Kevin lists in comment #11. Is there a better solution which addresses all of these concerns?
(In reply to Tim Lauridsen from comment #7) > Agree with Michael, that if the user ask to install X, dnf should not > install Y. This makes sense to me on first read, but on further thought, I don't think it's very different from _other_ behavior. For example, 'smtpd' is a virtual provides — we don't actually have a package named that. If I do `dnf install smtpd`, though, I get a package which provides it. The literal name I provided only one part of the picture, and that's actually quite powerful.
Hm, Kevin's comment applies also to the "dnf downgrade" command and I think that nobody is going to question that command. So I think this is not a good reason to reopen this bug. My opinion is that if a package explicitly Provides a higher version of a package, DNF should install it. If it Provides the same version, it doesn't matter which one is chosen. And if a package doesn't "Provide another package" (no matter whether it Obsoletes it or not), it shouldn't be installed because it potentially might not be the feature that was requested (because e.g. the interface (CLI/API/...) of the original package might have changed).
BTW, here's what zypper does: zypper has two modes, "install by NEVR" (--name, -n) and "install by provides" (--capability, -C). If neither --name or --capability is given, zypper tries to guess the user's intent: if a package with that name exists, it assumes --name, otherwise it prints a "Trying capabilities" warning and assumes --capability. (And this is just about provides, how should dnf behave if there is a obsoletes without the provides?)
As per [1], when package is being renamed/replaced, the provide must be given alongside the obsolete. That seems to be in alignment with what Radek suggested in comment 15 (version of the provide will be higher than the version of the original package). [1] http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
Yes, and as Ales pointed out in the comment 6, the guidelines allow you not to use Provides and also remove the Provides from some later release but this is probably the case when the new package is not compatible with the old one and thus I think this is still in alignment with my suggestion.
If you really switch to provides, you should also add an option to select NEVR matching. Also, 'dnf install foo-1-2' should also use NEVR matching.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
We need to consider global config option that would work for updates too. The other question is whether we want to replace the packages that obsoletes and provides feature at same time (change Fedora guidelines) or for any obsoletes.
Just another note, this seems to cause a problem for Fedora Remixes that are required to replace Fedora packages. For example, a user which has GNOME installed and wants to try Cinnamon will hit this: [11:01 chris ~]$ sudo dnf install @cinnamon-desktop Error: installed package korora-backgrounds-base-23.1.0-2.fc23.2.noarch obsoletes f23-backgrounds-base provided by f23-backgrounds-base-23.1.0-1.fc23.noarch (try to add '--allowerasing' to command line to replace conflicting packages) Adding --allowerasing will remove the korora-backgrounds rpms. As already noted, yum would just replace f23-backgrounds with the korora-backgrounds and move along happily. In this case, that would be the desired result. A way to enable yum-style logic might be beneficial.
Hmm, but the korora-backgrounds-base package *is* already installed, that's what the message said. So I wonder why dnf tries to install the f23-backgrounds again. Maybe it's a problem with how dnf resolves @cinamon-desktop, but that's not a solver problem.
@cinnamon-desktop is a comps group. If it explicitly lists f23-backgrounds, then this is as if the user did a dnf install f23-backgrounds (and all the other packages listed in the group).
*** Bug 1274899 has been marked as a duplicate of this bug. ***
DNF also seems to ignore Obsoletes/Provides pairs in regular Fedora packages, too. From what I've been told, it was a design decision. IMHO, this needs to be fixed, because the "correct" behavior is to use the package that has Obsoletes+Provides pair instead of ignoring it and letting you install the obsoleted package.
*** Bug 1291850 has been marked as a duplicate of this bug. ***
DNF could at least print hint that package is obsoleted by another package and let the user decide whether he wanted the former or obsoleting package.
@Jan: Michael Schröder's note in comment 16 of how Zypper does this is probably a way to go, but I'd amend it by at least printing something onscreen about the package being obsoleted when no switch is set and asking the user to make a decision. In non-interactive cases, ensure that the --assume-yes/-y triggers their processing automatically. I'd also like to see a configuration item for setting the default mode in dnf.conf, but I don't know if you'd want to do that. This is a really serious problem for Fedora packages, as well as downstream distros that build upon Fedora. It's making things harder than it should be.
*** Bug 1308631 has been marked as a duplicate of this bug. ***
I think asking doesn't make sense. At most you'd print an explanatory message. If people really want the obsolete package, they should be required to specify package name + version, as for any other outdated package (and if the version is specified explicitly, Obsoletes should not be processed).
*** Bug 1325941 has been marked as a duplicate of this bug. ***
*** Bug 1332830 has been marked as a duplicate of this bug. ***
Note this bit one of the users of my letsencrypt/certbot packages today and the error was entirely unhelpful: bz#1342249 The relevant packages (main and dependant subpackage) all have appropriate provides and obsoletes but there is no clue to the user that letsencrypt has been superseded by certbot on attempting to install it.
For what it is worth, Yum's behaviour was correct. Given that if you run "dnf install foo" there is a old foo in the repo, but in the meantime bar replaced foo. if you install foo, the next dnf update you will get bar updating foo. That is assuming that all of foo's deps are still available. If foo now has broken deps, users get an error that is less than useful. dnf should make it clear it is installing bar because it obsoletes and provides for foo. It is however the correct thing to do. take the letsencrypt example that ras reported in bz#1342249 the user wanted to just be able to make certs for his machine. does he really want letsencrypt? no he wants the functionality which is why we have obsoletes and provides when something does that.
I had the same problem with letsencrypt. Fortunately, I had read somewhere that the name was changing, so a little research led me to the right package. I thank that if there's an obsoletes, in almost every case, the user is going to want the new package, not the old one. Just print a message and if the user really wanted the original package, he'll have to specify it more precisely.
I have same problem, I think. On Fedora 23, python-gammu is no longer a sub-package of gammu and was renamed to python2-gammu. Anyway python2-gammu provides python-gammu rpm -q --provides python2-gammu python-gammu = 2.6-1.fc23 python-gammu(x86-64) = 2.6-1.fc23 python2-gammu = 2.6-1.fc23 python2-gammu(x86-64) = 2.6-1.fc23 so `dnf install python-gammu` should not try install old python-gammu package since a new one is provide by python2-gammu and that is a bug in dnf. dnf install python-gammu Error: package python-gammu-1.35.0-2.fc23.x86_64 requires gammu = 1.35.0-2.fc23, but none of the providers can be installed but should install python2-gammu-2.6 dnf install "python-gammu > 1.35" installs python2-gammu One reference was here: https://github.com/fedora-infra/the-new-hotness/issues/84#issuecomment-173061084 maybe relevant yum-3.4.3-507.fc23.noarch have same behaviour for [1], doesn't look for provides if match [1] yum-deprecated install python-gammu yum-deprecated install "python-gammu > 1.35"
It's been over a month since on the mailing list it was stated: "has a high priority in DNF team and we hope that it will be fixed soon" I'm *considering* retiring owncloud and obsoleting it with nextcloud at some point in the future[1] but that won't be feasible with this bug as it is. Is there any update that can be provided on the progress of this? [1] future may vary, see your local astrologer for details
(In reply to James Hogarth from comment #38) > It's been over a month since on the mailing list it was stated: > > "has a high priority in DNF team and we hope that it will be fixed soon" > > I'm *considering* retiring owncloud and obsoleting it with nextcloud at some > point in the future[1] but that won't be feasible with this bug as it is. > BTW if you plan to rename package or replace owncloud -> nextcloud then currently the safest is to do it fedora rawhide or alpha or beta versions of fedora. Because renamed package with provides will get very soon to "fedora" repository in development phase of fedora and you will not have old package "fedora" repository and renamed with provides in "updates" repository (or "updates-testing"). You cannot do it in stable version of fedora because packages are not changed in "fedora" repository (IIRC)
Soon (probably next week) there will be new PR available.
I have created a PR that will help. It changes searching priorities where first is taken in account provides and if no provides than the name. If someone wants to prefer another package, it can be customized by ver.release or using excludes. Please can you comment the PR or the bug-report if this changes are acceptable. https://github.com/rpm-software-management/dnf/pull/603
I don't think generally preferring Provides over a package actually having that name is a good idea at all. This really needs to take Obsoletes into account (i.e., ignore the package with the name only if it is obsolete, as yum did). I think there are several packages in Fedora where something else Provides their name, but neither of the packages is obsolete. In that case, the user should really get what he/she requested.
For the benefit of those keeping track of this bug before carrying out obsoletes of one package with another... The PR has been superseded by another one: https://github.com/rpm-software-management/dnf/pull/609 It has a failing build associated though and has not yet been merged.
*** Bug 1378729 has been marked as a duplicate of this bug. ***
*** Bug 1388544 has been marked as a duplicate of this bug. ***
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.
Is there a plan to backport PR 609 to fedora 23? or this BZ should be moved to f24
(In reply to Lukas Slebodnik from comment #47) > Is there a plan to backport PR 609 to fedora 23? > or this BZ should be moved to f24 no, only rawhide.
Unfortunately only for Fc26+ DNF-2.0 is planned to be released because the changes were so massive that it requires wide-change permission. It is possible to use testing version of DNF-2.0 for Fc24+ available from copr repository ('dnf copr enable rpmsoftwaremanagement/dnf-nightly').
When I can expect new version in rawhide? Currently I use dnf-2.0.0-0.rc1.4.fc26.noarch
I think that very soon (week or weeks).
(In reply to Jaroslav Mracek from comment #51) > I think that very soon (week or weeks). But it still doesn't fix original issue. https://github.com/rpm-software-management/ci-dnf-stack/blob/master/dnf-docker-test/features/install-obsoletes.feature#L1
This is only case when PackageB obsoletes PkgA but do not provide PkgA. If I am correct, the current behavior is according to Fedora guidelines about obsoletes.
You NEVER want to install an obsoleted package, even if there is nothing providing the replacement. Obsoletes alone needs to be enough. Adding Provides only makes sense when the replacement actually provides the functionality. But even when it does not, DNF must not install a package that the next dnf update will remove.
(In reply to Kevin Kofler from comment #54) > You NEVER want to install an obsoleted package, even if there is nothing > providing the replacement. Obsoletes alone needs to be enough. > > Adding Provides only makes sense when the replacement actually provides the > functionality. But even when it does not, DNF must not install a package > that the next dnf update will remove. yup, exactly.
Oh, and what should it do? Not install the update? Maybe there's a reason why the newer package no longer contains the obsoletes...
The case where "the newer package no longer contains the obsoletes" is different: if there is foo-1 that Obsoletes: bar and foo-2 that doesn't, then we want to ignore the Obsoletes in foo-1 and consider only foo-2 instead. We are talking about the case where foo has Obsoletes: bar and no Provides: bar. In that case, a dnf update will always replace foo with bar. So dnf install bar should install foo instead, even if it does not provide bar, because it does not make sense to install something that the next update will replace.
I don't think that makes sense. The user has requested 'bar' and not 'foo', after all. Maybe the user will then exclude bar from updates. You should not guess what the user wants. (And the update semantics can be changed to insist on the provides. The SOLVER_FLAG_NEED_UPDATEPROVIDE flag was added for Fedora, but you don't seem to use it.)
FYI for 90% cases the requested behavior is already implemented in DNF-2.0.rc2 which is in rawhide. Try it. The second case from comment 57 (with no provides) will be fixed afterwards.
(In reply to Kevin Kofler from comment #57) > The case where "the newer package no longer contains the obsoletes" is > different: if there is foo-1 that Obsoletes: bar and foo-2 that doesn't, > then we want to ignore the Obsoletes in foo-1 and consider only foo-2 > instead. > > We are talking about the case where foo has Obsoletes: bar and no Provides: > bar. In that case, a dnf update will always replace foo with bar. So dnf > install bar should install foo instead, even if it does not provide bar, > because it does not make sense to install something that the next update > will replace. Wait, even *I* don't understand what you're saying here. You're saying that you could suggest that things that Obsolete stuff should have an implicit Provides for the thing they Obsolete, so that they'd always install? That's completely broken. It ignores the semantics of how RPM dependency relationships are supposed to be handled.
The idea is that "dnf install bar" should not produce a state that "dnf update" will immediately modify, unless an old NEVR was explicitly requested.
I create a pull-request that use SOLVER_FLAG_NEED_UPDATEPROVIDE flag: https://github.com/rpm-software-management/libdnf/pull/230 I am close to neutral about to merge or not, but hope that all arguments for and against will be discussed. Some arguments are already discussed there.
(In reply to Kevin Kofler from comment #61) > The idea is that "dnf install bar" should not produce a state that "dnf > update" will immediately modify, unless an old NEVR was explicitly requested. That would mean that DNF would need to process Obsoletes on install, which is explicitly not supposed to happen.
But that is explicitly what this bug report is about (and what yum did).
(In reply to Kevin Kofler from comment #64) > But that is explicitly what this bug report is about (and what yum did). No. The original problem is that *even if* the new package also Provides the old name, DNF would not install the new package if it Obsoletes the old one. It would attempt to install the old one, and usually fail. Yum's output was misleading here: it only did this in cases where Obsoletes+Provides pair was set up. DNF usually treats this as the "replace" case. The "YumObsoletes" solver flag set in hawkey/libdnf is code in libsolv that explicitly was ported from the Yum code. What was not working (and this was fixed in DNF 2.0) was installing the package that has the Obsoletes+Provides pair using the *old package name*. Now, DNF follows the same expected behavior that Yum did in installing packages. You're additionally asking for it to artificially generate Provides for packages that may not exist (as the obsoletes could have been done to remove them from the system entirely). This is a no-go, differs from Yum, RPM, and everything else on how this particular dependency relationship works.
(In reply to Neal Gompa from comment #65) > You're additionally asking for it to artificially generate Provides for > packages that may not exist (as the obsoletes could have been done to remove > them from the system entirely). This is a no-go, differs from Yum, RPM, and > everything else on how this particular dependency relationship works. Just to make this clear: Doing this would have terrible consequences, leading the DNF making upgrades/distro-syncs/etc. far more brittle because it would be modifying the transaction as it was solving it. It would be entirely possible to end up with broken dependences and not know it because the transaction was modified in such a way that things that were Obsoleted without corresponding upgrade Provides were removed unnecessarily, because there were Provides injected that shouldn't have been. And of course, the dnfdb would be no help because by every indication, you replaced it correctly. Except, well, you didn't. So no. I will do my best to block any attempt to have DNF modifying transactions while a transaction is being solved.
It should not be considered a Provides for the purposes of fulfilling other packages' dependencies, only for the purposes of remapping the user request for the obsoleted package. And yum actually did that. In fact, how it worked in yum was that in a first step, it was doing the same thing DNF does, i.e., pulling in the obsolete package, and then it processed the Obsoletes and replaced the obsolete package with the obsoleting package. If the obsolete package is no longer in the repository, then both DNF and yum give an error that the package is not available, even if there are other packages with Obsoletes for it, e.g.: http://pkgs.fedoraproject.org/cgit/rpms/plasma-workspace.git/tree/plasma-workspace.spec#n274 both "dnf install kde-runtime-kuiserver" and "yum-deprecated install kde-runtime-kuiserver" error saying that there is no such package. If instead, I try the same thing on Kannolo 23, where kde-runtime-kuiserver is still in the repo (the Fedora 23 GA one), I get differently worded messages: sudo dnf install kde-runtime-kuiserver: Error: installed package plasma-workspace-5.7.5-2.fc23.x86_64 obsoletes kde-runtime-kuiserver < 1:15.08.2 provided by kde-runtime-kuiserver-16.04.1-1.fc23.x86_64 sudo yum-deprecated install kde-runtime-kuiserver: Package kde-runtime-kuiserver-16.04.1-1.fc23.x86_64 is obsoleted by plasma-workspace-5.7.5-2.fc23.x86_64 which is already installed Nothing to do OK, so maybe you do not yet see the difference from the error messages alone. So let's try Fedora 23 Xfce, where kde-runtime-kuiserver and plasma-workspace are in the repos, but neither is installed: sudo dnf install kde-runtime-kuiserver: wants to install 61 packages including the obsolete kde-runtime-kuiserver (i.e., the obsolete kde-runtime-kuiserver + 60 dependencies, DNF does not distinguish between "installing" and "installing for dependencies") sudo yum-deprecated install kde-runtime-kuiserver: Package kde-runtime-kuiserver is obsoleted by plasma-workspace, trying to install plasma-workspace-5.7.5-2.fc23.x86_64 instead Resolving dependencies [...] Installing: plasma-workspace [...] Installing for dependencies: [173 packages] Updating for dependencies: [4 packages] So in short, the old yum did NOT treat Obsoletes as Provides (so if the obsolete package is gone, you get the same error as with DNF), but it replaced the obsolete package (if it exists) with the obsoleting one in a separate pass to avoid installing obsolete packages.
(In reply to Kevin Kofler from comment #67) > If instead, I try the same thing on Kannolo 23, where kde-runtime-kuiserver > is still in the repo (the Fedora 23 GA one), I get differently worded > messages: > sudo dnf install kde-runtime-kuiserver: > Error: installed package plasma-workspace-5.7.5-2.fc23.x86_64 obsoletes > kde-runtime-kuiserver < 1:15.08.2 provided by > kde-runtime-kuiserver-16.04.1-1.fc23.x86_64 > sudo yum-deprecated install kde-runtime-kuiserver: > Package kde-runtime-kuiserver-16.04.1-1.fc23.x86_64 is obsoleted by > plasma-workspace-5.7.5-2.fc23.x86_64 which is already installed > Nothing to do > Testing with fedora 23 is not the best. because fixed version of dnf-2.0 which is only in rawhide.
hawkey-0.6.3-6.1.fc24 dnf-1.1.10-3.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2017-bfe06faa3f
dnf-1.1.10-5.fc25 hawkey-0.6.3-6.1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-cadae3ffee
I finally backported fix from libdnf to hawkey and stuff to dnf 1.x, so feel free to test it and leave karma.
dnf-1.1.10-3.fc24, hawkey-0.6.3-6.1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-bfe06faa3f
dnf-1.1.10-5.fc25, hawkey-0.6.3-6.1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-cadae3ffee
dnf-1.1.10-5.fc25, hawkey-0.6.3-6.1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
dnf-1.1.10-3.fc24, hawkey-0.6.3-6.1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
The behavior that was implemented is NOT what was requested. What was requested was: "If y Obsoletes x, DNF should pick y instead of x for 'dnf install x'." What was implemented is: "If y Provides x, DNF picks y instead of x for 'dnf install x'." So it prefers Provides even where there is no Obsoletes at all. In particular, requesting "kernel" in a kickstart no longer works, I get only kernel-core instead, because kernel-core Provides: kernel. There is no way to drag in the kernel metapackage. I cannot exclude kernel-core because kernel Requires kernel-core.
(In reply to Kevin Kofler from comment #76) > So it prefers Provides even where there is no Obsoletes at all. In > particular, requesting "kernel" in a kickstart no longer works, I get only > kernel-core instead, because kernel-core Provides: kernel. There is no way > to drag in the kernel metapackage. I cannot exclude kernel-core because > kernel Requires kernel-core. That's a pretty serious regression. We don't want to break everyone's kickstarts in this way.
"because kernel-core Provides: kernel" , if kernel-core provides kernel , it shouldn't be install the kernel , IMO dnf is correct ,
(In reply to Matthew Miller from comment #77) > (In reply to Kevin Kofler from comment #76) > > So it prefers Provides even where there is no Obsoletes at all. In > > particular, requesting "kernel" in a kickstart no longer works, I get only > > kernel-core instead, because kernel-core Provides: kernel. There is no way > > to drag in the kernel metapackage. I cannot exclude kernel-core because > > kernel Requires kernel-core. > > That's a pretty serious regression. We don't want to break everyone's > kickstarts in this way. This is a packaging error. kernel-core SHOULD NOT provide kernel while there is a metapackage called "kernel". If it's going to do that, then the kernel metapackage needs to be renamed to kernel-all. DNF is correct in handling Provides as equivalent to the name.
> kernel-all Actually, kernel-full would be a better name.
I would like to provide some information about current behavior of DNF-2.3: Example 1: pkgA-1-1 pkgB-1-1 (provides pkgA-2, obsoletes pkgA < 2) pkgC-1-1 (provides pkgA-3) With command "dnf install pkgA" dnf will install pkgB-1-1. With command "dnf install pkgA-1*" dnf will install pkgA-1-1. Example 2: pkgA-1-1 pkgB-1-1 (obsoletes pkgA < 2) pkgC-1-1 (provides pkgA-3) With command "dnf install pkgA" dnf will install pkgA-1-1. Example 3: pkgA-1-1 pkgB-1-1 (obsoletes pkgA < 2) pkgA-3-1 (provides pkgA-3) With command "dnf install pkgA" dnf will install pkgA-3-1. Please additional examples you can try by yourself after installing latest dnf from our test repository (dnf copr enable rpmsoftwaremanagement/dnf-nightly). I thimk that status in dnf-2.3 is well balanced for each user. Unfortunately we cannot find a better solution that will fit perfectly in every user-case. Also we cannot back-port the dnf-2.3 into fc25 according to Fedora regulations, but it will be part of fc26.
PS in Example 3 there should be pkgB-1-1 (provides pkgA-2, obsoletes pkgA < 2)
about kernel problem reported by Kevin Kofler maybe it is related with bug #1420754 , please check it . Thanks
To problem with kernel from Comment 76, I think that the problem was also solved with dnf-2.3. It can be tested from our test repository for Fedora 24+ "dnf copr enable rpmsoftwaremanagement/dnf-nightly". Please Kevin, can you try it and if any problem with dnf-2.3 appears don't hesitate to reopen the bug report or probably better to create new bug report. Thanks a lot.