0

I'm facing facing conflict issue while installing a RPM that is not already installed. I tried 'yum clean all' but it didn't change anything. Is the issue related to the package and not OS.

RHEL 7.7 x86_64

 [root@server dumps]# rpm -ivh pdksh-5.2.14-30.x86_64.rpm
warning: pdksh-5.2.14-30.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 4f2a6fd2: NOKEY
Preparing...                          ################################# [100%]
        file /usr/bin/ksh conflicts between attempted installs of pdksh-5.2.14-30.x86_64 and pdksh-5.2.14-30.x86_64
[root@server dumps]#
[root@server dumps]# ll /usr/bin/ksh
ls: cannot access /usr/bin/ksh: No such file or directory
[root@server dumps]#
[root@server dumps]# rpm -qa | grep -i ksh
[root@server dumps]#

1 Answer 1

0

You did not say where the package came from, but if that is the same version from Fedora Linux Core 3 then I see what the problem is.

The problem is that the pdksh-5.2.14-30.x86_64.rpm package is conflicting with itself. That is why the name is listed in the error twice.

If you look at rpm -qlp pdksh-5.2.14-30.x86_64.rpm, you would see a number of entries, but the conflicts are /bin/ksh and /usr/bin/ksh. Those used to be different locations in Fedora and they supplied two different files in the package. In your RHEL 7 system, the location /bin and /usr/bin are the same location, and an RPM cannot install two different files to the same location.

It appears that RedHat no longer packages pdksh and instead delivers mksh and ksh. If you cannot use one of those, I would suggest rebuilding the source package without installing files to /bin or just compiling the software from source.

2
  • I'm not aware from where the package was downloaded, someone else did but I can see it is available through access.redhat.com/downloads/content/package-browser Jan 26, 2021 at 5:42
  • The location of where the package was downloaded from would only be necessary if the contents differ from what I have described in my answer. Did you look at the output of rpm -qlp $YOUR_RPM_FILE? Does it have have the same files in both /bin and /usr/bin? If so, that is the source of your conflict. The solution would be to not use that package originally published in 2004, and instead find something built to be used with RHEL 7. Jan 26, 2021 at 21:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .