ldconfig creating bad symlink

According to my research, the (mis-)behaviour of ldconfig is triggered by the content of the file libbaccats-stub-9.0.6.so, specifically its SONAME field:

ts@xenon:~> objdump -p /usr/lib64/libbaccats-stub-9.0.6.so

/usr/lib64/libbaccats-stub-9.0.6.so:     file format elf64-x86-64
[...]
Dynamic Section:
  NEEDED               libc.so.6
  SONAME               libbaccats-9.0.6.so

Apparently that header tells ldconfig to create a symlink with that name.

Proof: If I rename libbaccats-stub-9.0.6.so to libbaccats-stub-9.0.6.so.BAD then ldconfig duly creates a symlink

libbaccats-7.4.4.so -> libbaccats-stub-7.4.4.so.BAD

and if I compress libbaccats-stub-9.0.6.so with gzip instead then ldconfig complains

ldconfig: /usr/lib64/libbaccats-stub-9.0.6.so.gz is not an ELF file - it has the wrong magic bytes at the start.

and leaves my libbaccats-7.4.4.so symlink alone.

So while I haven't found a way to make ldconfig create the correct symlink, there's at least a way to prevent it from recreating the wrong one: delete, compress or otherwise mangle the file /usr/lib64/libbaccats-stub-9.0.6.so.

Of course the real solution would be to set the SONAME field in libbaccats-stub-9.0.6.so correctly, but that would have to happen in the build process of the bacula-director package.