Description of problem: On F17 and Rawhide, a fresh install of the dkms package now names the executable as /usr/sbin/dkms.old, even though "rpm -ql dkms" indicates that it should be /usr/sbin/dkms. I have to move it manually. The postin scriptlet says [ -e /sbin/dkms ] && mv -f /sbin/dkms /sbin/dkms.old 2>/dev/null Due to the post-usrmove symlink from /sbin to /usr/sbin, this is the same as moving /usr/sbin/dkms to /usr/sbin/dkms.old. Version-Release number of selected component (if applicable): dkms-2.2.0.3-2.fc17
(In reply to comment #0) > Description of problem: > On F17 and Rawhide, a fresh install of the dkms package now names the > executable as /usr/sbin/dkms.old, even though "rpm -ql dkms" indicates that it > should be /usr/sbin/dkms. I have to move it manually. The postin scriptlet says > > [ -e /sbin/dkms ] && mv -f /sbin/dkms /sbin/dkms.old 2>/dev/null > > Due to the post-usrmove symlink from /sbin to /usr/sbin, this is the same as > moving /usr/sbin/dkms to /usr/sbin/dkms.old. > > Version-Release number of selected component (if applicable): > dkms-2.2.0.3-2.fc17 Can you please elaborate it? I tried to upgrade the dkms but I did not face the problem. which was the previous version of dkms and the OS on which you tried to upgrade? [root@sunil ~]# rpm -ivh dkms-2.2.0.2-1.noarch.rpm Preparing... ########################################### [100%] 1:dkms ########################################### [100%] [root@sunil ~]# rpm -q dkms dkms-2.2.0.2-1.noarch [root@sunil ~]# rpm -Uvh /tmp/test/dkms-2.2.0.3-1.fc17.noarch.rpm warning: /tmp/test/dkms-2.2.0.3-1.fc17.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID 1aca3465: NOKEY Preparing... ########################################### [100%] 1:dkms ########################################### [100%] [root@sunil ~]# cd /usr/sbin/ Display all 384 possibilities? (y or n) [root@sunil ~]# ls /usr/sbin/dkms* /usr/sbin/dkms [root@sunil ~]# rpm -q dkms dkms-2.2.0.3-1.fc17.noarch
Not sure why you're not able to reproduce it. Assuming you've done the usrmove conversion and have a symlink /sbin -> /usr/sbin, /sbin/dkms and /usr/sbin/dkms should be equivalent, so the postin scriptlet should always move /usr/sbin/dkms to /usr/sbin/dkms.old. As stated in comment 0, fresh install of dkms (dkms was not previously installed) OS: either F17 or Rawhide
To reproduce: 1. Verify that the symlink from /sbin to /usr/sbin exists, as it should on either F17 or Rawhide: [root@localhost ~]# ls -l /sbin lrwxrwxrwx. 1 root root 8 Feb 10 22:38 /sbin -> usr/sbin [root@localhost ~]# 2: Install or update dkms. Actual results: Due to the symlink, /usr/sbin/dkms is moved to /usr/sbin/dkms.old.
I can confirm this problem. Furthermore, it happens upon upgrades as well as new installs due to a lack of any logic in the re-naming. I would be surprised if that scriptlet line doesn't violate the packaging guidelines as it doesn't appear to make any sense for why it would be there. Commenting it out and rebuilding dkms has it behaving normally and as expected.
Found this in the changelog from over 8 years ago. I'm guessing the scriptlet line has been there ever since. Not sure why it would be necessary though since RPM should clean up the old version's files automatically, unless it was copied from a non-RPM version of the package. * Wed Oct 29 2003 Gary Lerhaupt <gary_lerhaupt> 0.41.10-1 - Added Red Hat specific kernel prep to avoid make dep (Thanks Matt Domsch) - Added dkms_mkkerneldoth script to support RH kernel prep - Moved dkms from /sbin/ to /usr/sbin - Fixed typo which caused original_module not to get replaced on uninstall - No longer edit Makefiles, just specify KERNELVERSION=$kernel_version on the command line - Removed unnecessary depmod during uninstall
Ok I can see the problem it seems symlinks are creating the problem.
The patch solves the problem . Submitted to upstream as well. --- dkms.spec 2012-01-09 16:11:09.000000000 -0500 +++ dkms.spec.orig 2012-02-23 14:25:35.953999530 -0500 @@ -5,7 +5,7 @@ Release: 1%{dist} License: GPLv2+ Group: System Environment/Base BuildArch: noarch -Requires: sed gawk findutils modutils tar cpio gzip grep mktemp +Requires: sed gawk findutils kmod tar cpio gzip grep mktemp Requires: bash > 1.99 # because Mandriva calls this package dkms-minimal Provides: dkms-minimal = %{version} @@ -116,7 +116,9 @@ rm -rf $RPM_BUILD_ROOT %post -[ -e /sbin/dkms ] && mv -f /sbin/dkms /sbin/dkms.old 2>/dev/null +if [ %{_sbindir} == /sbin ]; then + mv -f /sbin/dkms /sbin/dkms.old 2>/dev/null +fi # enable on initial install [ $1 -lt 2 ] && /sbin/chkconfig dkms_autoinstaller on ||:
The upstream post is here: http://lists.us.dell.com/pipermail/dkms-devel/2012-February/001068.html
Nominating this for CommonBugs. The problem is that due to usrmove, the postin scriptlet (which is over 8 years old) [ -e /sbin/dkms ] && mv -f /sbin/dkms /sbin/dkms.old 2>/dev/null now has the effect of renaming the dkms executable as dkms.old, so it's not found after installation, unless it's renamed back. Hence the package is broken out of the box.
Adding some details since this problem remains in dkms-2.2.0.3-2.fc17: $ ls /usr/sbin/dkms.old ls: cannot access /usr/sbin/dkms.old: No such file or directory $ rpm -q dkms package dkms is not installed $ sudo yum install dkms ... Installing: dkms noarch 2.2.0.3-2.fc17 fedora 105 k ... Installed: dkms.noarch 0:2.2.0.3-2.fc17 Complete! $ rpm -V dkms missing /usr/sbin/dkms $ ls /usr/sbin/dkms.old /usr/sbin/dkms.old* $ file /usr/sbin/dkms.old /usr/sbin/dkms.old: Bourne-Again shell script, ASCII text executable, with very long lines $ rpm -qf /usr/sbin/dkms.old file /usr/sbin/dkms.old is not owned by any package Because it is not owned by any package, it will not be removed by an un-install/erase action by yum or rpm.
subscribe
> -[ -e /sbin/dkms ] && mv -f /sbin/dkms /sbin/dkms.old 2>/dev/null > +if [ %{_sbindir} == /sbin ]; then > + mv -f /sbin/dkms /sbin/dkms.old 2>/dev/null > +fi That stupid mv should just be removed entirely instead. RPMs shouldn't be moving around files which don't belong to them.
There was never any response from upstream. In light of this, I agree with Kevin.
Same problem with a fresh install. I had to rename /sbin/dkms.old and /usr/sbin/dkms.old to get dkms working.
Dear dkms maintainer, this bug is trivial to fix, a correction has already been proposed (just remove the offending mv line), and several people are complaining about it. Please fix it! If you do not fix the bug (and file an update in Bodhi to fix it on Fedora 17) within the next 48 hours, I will use my provenpackager powers to fix it. Thanks in advance for your understanding.
Kevin, I have contacted upstream maintainer for this, I should be able to fix this in a day or two. Thanks, Sunil
Well, please fix this quickly. We I also don't see why you need to contact the upstream maintainer. You only need to remove one line from the Fedora specfile in Fedora dist-git. There is no requirement in Fedora that our specfile matches the upstream one, and in fact it is almost never the case, because upstream specfiles rarely comply to our packaging guidelines. In particular, trying to move a file which does not belong to the package is a bad idea even when it works as intended.
(Oops, I sent the previous message too quickly.) Well, please fix this quickly. The problem was reported to you almost 4 months ago, well over 3 months before the Fedora 17 release. Now Fedora 17 is released and many users are being hit by the bug, completely unnecessarily, because it should not take 4 months to remove a line from a specfile! The more you delay fixing it, the more users are hit by this stupid bug. I also don't see why you need to contact the upstream maintainer. You only need to remove one line from the Fedora specfile in Fedora dist-git. There is no requirement in Fedora that our specfile matches the upstream one, and in fact it is almost never the case, because upstream specfiles rarely comply to our packaging guidelines. In particular, trying to move a file which does not belong to the package is a bad idea even when it works as intended.
the patch is committed in upstream http://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=dkms.git;a=commit;h=e98e7a355dcaad128c00b0bde4ed883e0f5a20d6 I am in process of committing it in fedora will update once done. Thanks, Sunil
dkms-2.2.0.3-3.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/dkms-2.2.0.3-3.fc17
Hello sunil, thanks for fixing this. Being a contributor to the OS community myself, I hate ranting, but I am not happy taking it 14 weeks to apply the (rather simple) fix. I can confirm that dkms-2.2.0.3-3.fc17 fixes it. However, it still leaves the .old files on the system: [nazgul@rivendell ~]$ rpm -qv dkms dkms-2.2.0.3-2.fc17.noarch [nazgul@rivendell ~]$ ls /sbin/dkms.old /sbin/dkms.old [nazgul@rivendell ~]$ ls /usr/sbin/dkms.old /usr/sbin/dkms.old [nazgul@rivendell ~]$ sudo rpm -U dkms-2.2.0.3-3.fc17.noarch.rpm [nazgul@rivendell ~]$ rpm -qv dkms dkms-2.2.0.3-3.fc17.noarch [nazgul@rivendell ~]$ ls /usr/sbin/dkms* /usr/sbin/dkms /usr/sbin/dkms.old [nazgul@rivendell ~]$ ls /sbin/dkms* /sbin/dkms /sbin/dkms.old
(In reply to comment #21) > I can confirm that dkms-2.2.0.3-3.fc17 fixes it. > > However, it still leaves the .old files on the system: Personally, I think that's best. The problem happened originally because the package insisted on tampering with files that didn't belong to it. Trying to remove the dkms.old file would require a temporary patch that would continue that bad practice (since the dkms.old file doesn't belong to either the old or new versions of the package). The patch would have to be removed eventually, before then it might actually remove a dkms.old file that came from somewhere else (although the dkms.old file *probably* came from the old broken version of the package, there's no guarantee of that), most users will never even notice the dkms.old file, and if they do they can remove it manually.
(In reply to comment #22) > Personally, I think that's best. The problem happened originally because the > package insisted on tampering with files that didn't belong to it. I should have said "that it *thought* didn't belong to it", since /sbin/dkms actually *did* belong to it, thanks to usrmove. But it's a bad practice anyway.
Package dkms-2.2.0.3-3.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dkms-2.2.0.3-3.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-8942/dkms-2.2.0.3-3.fc17 then log in and leave karma (feedback).
(In reply to comment #24) > Please go to the following url: > https://admin.fedoraproject.org/updates/FEDORA-2012-8942/dkms-2.2.0.3-3.fc17 > then log in and leave karma (feedback). All concerned - please test this, it needs one more +1 to go to stable.
dkms-2.2.0.3-3.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.