Comment 4 for bug 2022088

I am not happy with this implementation and will not approve it for an SRU.

- ld.so.conf is for configuring shared library paths. But Debian policy says shared libraries in packages should be in one of /lib, /usr/lib, /lib/$(multiarch), or /usr/lib/$(multiarch). If these objects should be on the shared library path, then they should be shipped in these directories with no need for changing the global shared library path.

- and the path is global, so now every library lookup has two other directories it's looking in. The speed impact on program start is negligible, but it also can result in unexpected behavior due to hidden conflicts between files in the two directories. If the shared libraries are shipped in the expected /usr/lib/$arch path, then the package manager would detect conflicts between two packages trying to ship the same library name, instead of letting the user install the same library name in two directories and giving unexpected behavior at runtime.

- but p11sak isn't using libopencryptoki.so as a shared library *anyway*, it's using it as a plugin. Plugins shouldn't be on the system library path. I don't know why a tool that comes from the opencryptoki source package allows overriding loading of the library shipping from the same source package, but anyway you can get the same net result, without polluting the global library path, by setting default_pkcs11lib to libopencryptoki.so.0 instead of libopencryptoki.so. This should be reasonably stable and not result in maintenance burden, because the libopencryptoki ABI is defined by PKCS11 itself so an ABI change resulting in an SONAME change is highly unlikely!