search

besser82 / libxcrypt

Extended crypt library for descrypt, md5crypt, bcrypt, and others
GNU Lesser General Public License v2.1
178 stars 49 forks source link

libcrypt.so.1 is listed as installed with different paths in el8 and el7/el9/amazonlinux2023 #169

Closed jsolomon8080 closed 1 year ago

jsolomon8080 commented 1 year ago

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.

besser82 commented 1 year ago

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.

jsolomon8080 commented 1 year ago

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!