So far TexLive is the only package that we don't install from source, we just use Texlive's own package manager to download the proper binary files for the user's architecture.

Because of this we recently confronted this error on a system:

biber: error while loading shared libraries: libnsl.so.1: cannot open shared object file: No such file or directory

Indeed, when I check the libraries that the Texlive Biber links with, I see this:

$ ldd .local/bin/biber
        linux-vdso.so.1 (0x00007fff727fd000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fa1ed6e3000)
        libnsl.so.1 => /usr/lib/libnsl.so.1 (0x00007fa1ed6c8000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fa1ed6c3000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007fa1ed57d000)
        libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x00007fa1ed543000)
        libutil.so.1 => /usr/lib/libutil.so.1 (0x00007fa1ed53e000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fa1ed379000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fa1ed73a000)

So its not just libnsl, but libcrypt is another high-level library that can cause a similar crash.

This is very bad and in task #15267 (Building TeXLive from source) we plan to fix this problem. But that will be a long task, because TeX packages have their own unique style of building which I don't have time to implement within the pipeline now.

In a recent commit, I added `libnsl' (and its dependencies of `libtirpc' and `rpcsvc') to the template, but unfortunately they are an updated version and there is no guarantee when the Texlive builders decide to update their dependency on the libraries.

Until then, we'll have to ask any user that confronts this problem to either ignore a LaTeX PDF output, or install libnsl and libcrypt manually using their system's package manager. For example on Red-hat based GNU/Linux machines they should run this command:

sudo dnf install libnsl libxcrypt-compat