Bug 1257713 - dnf does not know about the /usr/sbin(/depmod) -> /sbin(/depmod) symlink even if the link already exists
dnf does not know about the /usr/sbin(/depmod) -> /sbin(/depmod) symlink even...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-27 14:28 EDT by m
Modified: 2015-09-16 11:02 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-16 10:31: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 m 2015-08-27 14:28:50 EDT
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 09:36:50 EDT
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-09 22:10:20 EDT
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 12:28:00 EDT
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 13:35:35 EDT
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 13:59:31 EDT
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 10:31:29 EDT
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 10:54:20 EDT
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 11:02:43 EDT
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.