Distros have been dropping glibc's libcrypt in favour of libxcrypt which features backwards compatibility for glibc.

Mostly it seems to be wanting a more agile library not tied to glibc that supports modern hashing techniques (yescrypt).

In glibc 2.28's release notes glibc mention wanting to hand off maintenance of libcrypt

Quoted Text * We have tentative plans to hand off maintenance of the passphrase-hashing library, libcrypt, to a separate development project that will, we hope, keep up better with new passphrase-hashing algorithms. We will continue to declare 'crypt' in <unistd.h>, and programs that use 'crypt' or 'crypt_r' should not need to change at all; however, distributions will need to install <crypt.h> and libcrypt from a separate project.

Quoted Text * In this release, if the configure option --disable-crypt is used, glibc will not install <crypt.h> or libcrypt, making room for the separate project's versions of these files. The plan is to make this the default behavior in a future release.

Fedora's reasoning; https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
Arch Linux's reasoning: https://bugs.archlinux.org/task/67312
Debian mini-blog: https://blog.bofh.it/debian/id_458

This would involve building glibc with --disable-crypt enabled. Packaging libxcrypt and then rebuilding all packages that link against libcrypt.so.