Bug 1257713 - dnf does not know about the /usr/sbin(/depmod) -> /sbin(/depmod) symlink even if the link already exists
Summary: dnf does not know about the /usr/sbin(/depmod) -> /sbin(/depmod) symlink even...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-27 18:28 UTC by m
Modified: 2015-09-16 15:02 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-09-16 14:31:29 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description m 2015-08-27 18:28:50 UTC
Description of problem:

dnf does not properly identify dependencies from other rpm packages and fails to install.
In the example below, /sbin/depmod is in fact a softlink to ../bin/kmod and provided by the kmod rpm.

$ dnf install kmod-ethercat
Error: nothing provides /sbin/depmod needed by kmod-ethercat-1.5.2-2.fc22.x86_64

$ dnf whatprovides /sbin/depmod
Error: No Matches found

$ rpm -q --whatprovides /sbin/depmod
kmod-21-1.fc22.x86_64


Version-Release number of selected component (if applicable):
dnf-0:1.1.0-2.fc22.noarch

Comment 1 Radek Holy 2015-09-01 13:36:50 UTC
Hello, this is not a bug in DNF.

The kmod package does not *provide* "/sbin/depmod". I mean, it's not listed neither in the "%files" section nor in a "Provides:" tag. DNF has no (reasonable) way how to discover/predict that once it installs given package on your system there will be a symlink pointing to a file it has installed.

There is a special code in RPM which causes "rpm -q --whatprovides" to discover the symlink. We did not add this to DNF since "dnf whatprovides /sbin/depmod" would behave differently based on whether "kmod" is installed on the system or not. See the bug 1230866 for the discussion (and let's discuss it there if needed).

You can also see these relevant guidelines: https://fedoraproject.org/w/index.php?title=Packaging:Guidelines&oldid=419167#Effect_of_the_UsrMove_Fedora_Feature

Either way, it's not a bug in DNF. It should be fixed in the kmod-ethercat package. It should require /usr/sbin/depmod. I'd switch this to the "kmod-ethercat" component but it seems that it is not part of Fedora, so I'm just closing this.

Comment 2 m 2015-09-10 02:10:20 UTC
I am not arguing this is a bug in dnf. But rpm packagers might rely on previous yum behavior and not realize it. rpm guidelines may need an update saying more explicitly "Provides x,y,z..." or incompatibilities may result (e.g., soft links, etc.)

Comment 3 Radek Holy 2015-09-10 16:28:00 UTC
Uh, I didn't know that it works with YUM. And actually, the YUM's behaviour is very confusing for me:

$ rm -rf /tmp/root
$ yum-deprecated --installroot /tmp/root --releasever 22 install foo-1-1.x86_64.rpm 
Yum command has been deprecated, use dnf instead.
See 'man dnf' and 'man yum2dnf' for more information.

Examining foo-1-1.x86_64.rpm: foo-1-1.x86_64
Marking foo-1-1.x86_64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package foo.x86_64 0:1-1 will be installed
--> Processing Dependency: /sbin/depmod for package: foo-1-1.x86_64
fedora/22/x86_64/metalink                                   |  22 kB  00:00     
updates/22/x86_64/metalink                                  |  15 kB  00:00     
--> Processing Dependency: /sbin/depmod for package: foo-1-1.x86_64
--> Finished Dependency Resolution
Error: Package: foo-1-1.x86_64 (/foo-1-1.x86_64)
           Requires: /sbin/depmod
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest




$ yum-deprecated --installroot /tmp/root --releasever 22 install kmod
[...]
  Installing : kmod-21-1.fc22.x86_64                                      21/21 
[...]
Complete!
$ yum-deprecated --installroot /tmp/root --releasever 22 install foo-1-1.x86_64.rpm 
Yum command has been deprecated, use dnf instead.
See 'man dnf' and 'man yum2dnf' for more information.

Examining foo-1-1.x86_64.rpm: foo-1-1.x86_64
Marking foo-1-1.x86_64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package foo.x86_64 0:1-1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package       Arch             Version         Repository                 Size
================================================================================
Installing:
 foo           x86_64           1-1             /foo-1-1.x86_64           0.0  

Transaction Summary
================================================================================
Install  1 Package

Installed size: 0  
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : foo-1-1.x86_64                                               1/1 
warning: Unable to get systemd shutdown inhibition lock
  Verifying  : foo-1-1.x86_64                                               1/1 

Installed:
  foo.x86_64 0:1-1                                                              

Complete!


It is able to install a package which "Requires: /sbin/depmod" only if kmod is *already installed*. If it isn't installed, it fails the same as DNF. I guess that it behaves so exactly because of the RPM's behaviour...

So, let's discuss this within the team but I don't expect we will do the same as YUM. But yes, we should at least document the difference.

Comment 4 m 2015-09-10 17:35:35 UTC
I suspect kmod is *always already installed*, at least trying to remove it gives:

on f22:
# dnf remove kmod
Dependencies resolved.
Error: The operation would result in removing the following protected packages: systemd, dnf.

on f21:
#yum remove kmod
...
Error: Trying to remove "systemd", which is protected

Comment 5 Radek Holy 2015-09-10 17:59:31 UTC
AFAIK, in containers, they are trying to get rid of systemd. Maybe they wouldn't need kmod then as well. Anyway, this is just one case. There are surely a lot of other packages installing files into /usr/sbin and some of them might not be installed by default even on normal system. We need to find a general solution.

Comment 6 Radek Holy 2015-09-16 14:31:29 UTC
OK, we have discussed it and we again came to the conclusion that we are not going to implement this confusing behaviour. kmod-ethercat should rather require /usr/sbin/depmod.

Comment 7 m 2015-09-16 14:54:20 UTC
Ok, thanks for the follow up.

For completness, the fix is not Require: /usr/sbin/depmod (since dnf does not know how it's provided) but Require: kmod

This is actually embedded in the redhat-rpm-config's kmodtool so I will refer the bug there.

Comment 8 m 2015-09-16 15:02:43 UTC
oops, I see now... retracting my previous comment.


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