Bug 1096506 - promoting 'install a' to 'install b' when b obsoletes a
promoting 'install a' to 'install b' when b obsoletes a
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jaroslav Mracek
Fedora Extras Quality Assurance
: Reopened, Triaged
: 1274899 1291850 1308631 1325941 1378729 1388544 (view as bug list)
Depends On:
Blocks: 1351007
  Show dependency treegraph
 
Reported: 2014-05-11 07:30 EDT by Jiri Moskovcak
Modified: 2017-04-19 11:17 EDT (History)
29 users (show)

See Also:
Fixed In Version: dnf-1.1.10-5.fc25 dnf-1.1.10-3.fc24
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-04-19 11:17:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jiri Moskovcak 2014-05-11 07:30:57 EDT
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.
Comment 1 Ales Kozumplik 2014-05-12 02:37:16 EDT
Hello Jiri, can you attach the solver debug data [1]? Many thanks.

[1] http://dnf.baseurl.org/2013/11/25/reporting-depsolving-bugs/
Comment 2 Jiri Moskovcak 2014-05-12 03:22:35 EDT
http://jmoskovc.fedorapeople.org/debugdata.zip
Comment 3 Ales Kozumplik 2014-05-13 02:56:07 EDT
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.
Comment 4 Ales Kozumplik 2014-05-13 03:07:59 EDT
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.
Comment 5 Michael Schröder 2014-05-13 05:57:59 EDT
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.
Comment 6 Ales Kozumplik 2014-05-13 07:09:52 EDT
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.
Comment 7 Tim Lauridsen 2014-05-13 08:58:55 EDT
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 :)
Comment 8 Ales Kozumplik 2014-05-13 09:11:13 EDT
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.
Comment 9 Fedora Update System 2014-05-28 08:09:22 EDT
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
Comment 10 Fedora Update System 2014-05-28 19:49:17 EDT
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).
Comment 11 Kevin Kofler 2014-05-30 21:14:53 EDT
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.
Comment 12 Fedora Update System 2014-05-31 19:57:49 EDT
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.
Comment 13 Matthew Miller 2015-03-09 14:49:29 EDT
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?
Comment 14 Matthew Miller 2015-03-09 18:04:13 EDT
(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.
Comment 15 Radek Holy 2015-03-10 06:08:14 EDT
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).
Comment 16 Michael Schröder 2015-03-10 08:41:25 EDT
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?)
Comment 17 Jan Zeleny 2015-03-10 10:17:31 EDT
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
Comment 18 Radek Holy 2015-03-11 07:58:25 EDT
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.
Comment 19 Michael Schröder 2015-03-11 08:04:45 EDT
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.
Comment 20 Jan Kurik 2015-07-15 10:40:47 EDT
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
Comment 21 Honza Silhan 2015-07-20 05:51:22 EDT
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.
Comment 22 Chris Smart 2015-12-16 19:07:30 EST
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.
Comment 23 Michael Schröder 2015-12-17 06:00:08 EST
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.
Comment 24 Kevin Kofler 2015-12-17 07:45:42 EST
@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).
Comment 25 Neal Gompa 2016-01-07 18:55:10 EST
*** Bug 1274899 has been marked as a duplicate of this bug. ***
Comment 26 Neal Gompa 2016-01-07 18:57:29 EST
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.
Comment 27 Honza Silhan 2016-01-13 13:21:33 EST
*** Bug 1291850 has been marked as a duplicate of this bug. ***
Comment 28 Honza Silhan 2016-01-19 04:15:38 EST
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.
Comment 29 Neal Gompa 2016-02-20 23:22:12 EST
@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.
Comment 30 Honza Silhan 2016-02-22 07:27:19 EST
*** Bug 1308631 has been marked as a duplicate of this bug. ***
Comment 31 Kevin Kofler 2016-02-22 20:19:42 EST
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).
Comment 32 Honza Silhan 2016-05-02 07:14:13 EDT
*** Bug 1325941 has been marked as a duplicate of this bug. ***
Comment 33 Honza Silhan 2016-05-09 07:46:59 EDT
*** Bug 1332830 has been marked as a duplicate of this bug. ***
Comment 34 James Hogarth 2016-06-02 15:25:44 EDT
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.
Comment 35 Dennis Gilmore 2016-06-02 16:53:17 EDT
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.
Comment 36 Samuel Sieb 2016-06-02 17:24:03 EDT
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.
Comment 37 Sergio Monteiro Basto 2016-06-29 23:00:06 EDT
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"
Comment 38 James Hogarth 2016-07-14 11:19:54 EDT
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
Comment 39 Lukas Slebodnik 2016-07-14 12:04:34 EDT
(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)
Comment 40 Jaroslav Mracek 2016-09-09 05:36:57 EDT
Soon (probably next week) there will be new PR available.
Comment 41 Jaroslav Mracek 2016-09-12 05:17:34 EDT
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
Comment 42 Kevin Kofler 2016-09-12 07:29:39 EDT
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.
Comment 43 James Hogarth 2016-09-20 06:33:44 EDT
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.
Comment 44 Igor Gnatenko 2016-09-23 04:40:45 EDT
*** Bug 1378729 has been marked as a duplicate of this bug. ***
Comment 45 Jeremy Cline 2016-10-26 10:01:11 EDT
*** Bug 1388544 has been marked as a duplicate of this bug. ***
Comment 46 Fedora End Of Life 2016-11-24 06:09:47 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 47 Lukas Slebodnik 2016-11-24 06:21:08 EST
Is there a plan to backport PR 609 to fedora 23?
or this BZ should be moved to f24
Comment 48 Igor Gnatenko 2016-11-24 06:22:33 EST
(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.
Comment 49 Jaroslav Mracek 2016-11-24 07:15:54 EST
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').
Comment 50 Lukas Slebodnik 2016-11-24 07:21:03 EST
When I can expect new version in rawhide?
Currently I use dnf-2.0.0-0.rc1.4.fc26.noarch
Comment 51 Jaroslav Mracek 2016-11-25 10:20:44 EST
I think that very soon (week or weeks).
Comment 52 Igor Gnatenko 2016-11-25 11:02:40 EST
(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
Comment 53 Jaroslav Mracek 2016-11-25 11:50:59 EST
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.
Comment 54 Kevin Kofler 2016-11-25 13:01:21 EST
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.
Comment 55 Igor Gnatenko 2016-11-25 13:30:30 EST
(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.
Comment 56 Michael Schröder 2016-11-28 04:52:37 EST
Oh, and what should it do? Not install the update? Maybe there's a reason why the newer package no longer contains the obsoletes...
Comment 57 Kevin Kofler 2016-11-28 07:58:34 EST
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.
Comment 58 Michael Schröder 2016-11-28 08:07:34 EST
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.)
Comment 59 Honza Silhan 2016-12-06 08:58:25 EST
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.
Comment 60 Neal Gompa 2016-12-15 03:25:43 EST
(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.
Comment 61 Kevin Kofler 2016-12-15 05:57:26 EST
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.
Comment 62 Jaroslav Mracek 2016-12-20 14:21:48 EST
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.
Comment 63 Neal Gompa 2016-12-21 14:37:21 EST
(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.
Comment 64 Kevin Kofler 2016-12-21 22:43:37 EST
But that is explicitly what this bug report is about (and what yum did).
Comment 65 Neal Gompa 2016-12-21 22:53:56 EST
(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.
Comment 66 Neal Gompa 2016-12-21 23:00:29 EST
(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.
Comment 67 Kevin Kofler 2016-12-21 23:48:24 EST
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.
Comment 68 Lukas Slebodnik 2017-01-04 03:36:46 EST
(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.
Comment 69 Fedora Update System 2017-01-17 11:01:00 EST
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
Comment 70 Fedora Update System 2017-01-17 11:21:44 EST
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
Comment 71 Igor Gnatenko 2017-01-17 12:32:46 EST
I finally backported fix from libdnf to hawkey and stuff to dnf 1.x, so feel free to test it and leave karma.
Comment 72 Fedora Update System 2017-01-19 02:22:24 EST
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
Comment 73 Fedora Update System 2017-01-19 04:09:55 EST
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
Comment 74 Fedora Update System 2017-01-20 13:06:04 EST
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.
Comment 75 Fedora Update System 2017-01-20 13:18:57 EST
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.
Comment 76 Kevin Kofler 2017-04-15 19:49:32 EDT
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.
Comment 77 Matthew Miller 2017-04-16 09:15:58 EDT
(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.
Comment 78 Sergio Monteiro Basto 2017-04-16 11:05:45 EDT
 "because kernel-core Provides: kernel" , if kernel-core provides kernel , it shouldn't be install the kernel , IMO dnf is correct ,
Comment 79 Neal Gompa 2017-04-16 12:44:44 EDT
(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.
Comment 80 Neal Gompa 2017-04-16 12:45:21 EDT
> kernel-all

Actually, kernel-full would be a better name.
Comment 81 Jaroslav Mracek 2017-04-19 05:56:27 EDT
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.
Comment 82 Jaroslav Mracek 2017-04-19 05:58:29 EDT
PS in Example 3 there should be pkgB-1-1 (provides pkgA-2, obsoletes pkgA < 2)
Comment 83 Sergio Monteiro Basto 2017-04-19 06:35:27 EDT
about kernel problem reported by  Kevin Kofler maybe it is related with bug #1420754 , please check it . Thanks
Comment 84 Jaroslav Mracek 2017-04-19 11:17:29 EDT
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.

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