libcrypt.so.1 is listed as installed with different paths in el8 and el7/el9/amazonlinux2023
jsolomon8080 opened this issue · 2 comments
Our product ships as an rpm and we build on CentOS 7 and expect the code to run on el7, el8 and el9 (among others). We ship almost everything we link against but not glibc and other system-ish libraries. Our rpm lists its dependencies so that if you install our rpm, the package manager (yum/dnf) will install the dependencies. Our product depends on libcrypt.so.1
because we build on CentOS7. Because glibc is always already installed on el7 and libxcrypt
is always installed on el8, we actually don't list either as an explicit dependency of our rpm.
On el9 however, specifically Amazonlinux2023, libxcrypt-compat
, is not installed by default so we must specify it somehow. Seems like libxcrypt-compat
is installed by default in the other el9 based distros we have checked, but I guess it wouldn't have to be since el9 uses libxcrypt.so.2
.
Because our rpm needs to work on el7, 8 and 9 we can't list libxcrypt-compat
as a dependency because it won't exist on el7 and el8. However, yum/dnf support a neat feature where you can yum/dnf install <file path>
and it will map that path back to a package and install it. So in theory, all my problems are solved if I could list /usr/lib64/libcrypt.so.1
as an rpm dependency. On el7, that is mapped to glibc
, on el8, libxcrypt
and on el9, it's mapped to libxcrypt-compat
.
Sounds perfect...except that the el8 version of libxcrypt
uses the path /lib64/libcrypt.so.1
instead of /usr/lib64/libcrypt.so.1
.
[root@71850e774fc9 /]# grep PLATFORM /etc/os-release
PLATFORM_ID="platform:el8"
[root@71850e774fc9 /]# rpm -ql libxcrypt
/lib64/libcrypt.so.1
/lib64/libcrypt.so.1.1.0
If you run the same-ish commands on el7 and el9, you see the path /usr/lib64/libcrypt.so.1
. If you say:
dnf install /usr/lib64/libcrypt.so.1
you get an error on el8, while if you remove the /usr
, it works.
It would be great if this path hadn't changed. Is this a bug? If so, is fixing it in scope for this project or somehow controlled by the consuming distros?
BTW, the path /usr/lib64/libcrypt.so.1
absolutely exists on el8, it's just not listed as part of the libxcrypt
package so you can't install with it.
Hello, and thanks for your question,
from my understanding of the autogenerated rpm dependencies none of your mentioned explicit Requires
are neccessary, as libxcrypt-compat exposes quite a set of rpm autogenerated Provides
:
libcrypt.so.1()(64bit)
libcrypt.so.1(GLIBC_2.2.5)(64bit)
libcrypt.so.1(XCRYPT_2.0)(64bit)
libcrypt.so.1(XCRYPT_4.3)(64bit)
libcrypt.so.1(XCRYPT_4.4)(64bit)
Your distributed binary rpm file built on el7 should ship autogenerated Requires
to one of these (usually for libcrypt.so.1(GLIBC_.*)), and thus pull the implementation of libcrypt.so.1 offered by the corresponding distribution, if not installed already.
You can verify the Requires
of your built rpm file using: rpm -qpR $file.rpm
.
If you are unsure about the correct autogenerated Requires
, you can paste the output of the above command here, and I will check and offer some further advice.
Thank you for the info. I obviously wasn't fully aware of the ways that RPMs specify dependencies. I was able to use one of the ones you listed to satisfy our needs. Thanks again!