There might be a way to work around it with the "alternatives" command, but since it now would have to contain the version number, we'd have to re-run alternatives on every update. I don't think that is acceptable.
Hello, no problem for the noise. This is due to the horrible way of selecting the database that Bacula has. It depends on a library soname that no one provides so you need to rely on a symlink. Any tool (RPM, etc.) at build time flags that as unacceptable and you need workarounds. This is why the alternative is set with the unversioned library:
Alternatives is also configured to provide a default, so you should never ever run it again except at install time when selecting the database (please read the included README in the bacula-common package).
It's all in the README in the bacula-common package: /usr/share/doc/bacula-common/README.Redhat
The symlink gets created when you install the package. I guess you can just try removing everything and reinstalling. If you prefer to fix it manually:
If alternatives creates "libbaccats-9.0.7.so -> libbaccats.so" for you, then there is something that is keeping it from working properly for me. I'd like to figure out what that is...
This update has been submitted for testing by slaanesh.
I tried bacula-9.0.7-4.fc28 but it still has problems. Specifically, while it installs, it won't run. /var/log/messages shows why:
/usr/sbin/bacula-dir: error while loading shared libraries: libbaccats-9.0.7.so: cannot open shared object file: No such file or directory
When I look in /usr/lib64, I see:
saf# ll /usr/lib64/libbaccats -rwxr-xr-x 1 root root 36296 Jun 11 07:02 /usr/lib64/libbaccats.so -rwxr-xr-x 1 root root 24096 Jun 11 07:02 /usr/lib64/libbaccats-sqlite3.so -rwxr-xr-x 1 root root 24096 Jun 11 07:02 /usr/lib64/libbaccats-sqlite3-9.0.7.so -rwxr-xr-x 1 root root 36296 Jun 11 07:02 /usr/lib64/libbaccats-postgresql.so -rwxr-xr-x 1 root root 36296 Jun 11 07:02 /usr/lib64/libbaccats-postgresql-9.0.7.so -rwxr-xr-x 1 root root 28136 Jun 11 07:02 /usr/lib64/libbaccats-mysql.so -rwxr-xr-x 1 root root 28136 Jun 11 07:02 /usr/lib64/libbaccats-mysql-9.0.7.so
As you can see, there is no library libbaccats-9.0.7.so so bacula-dir won't run.
I can work around it by doing:
saf# cd /usr/lib64 saf# ln -s libbaccats-postgresql-9.0.7.so libbaccats-9.0.7.so
There might be a way to work around it with the "alternatives" command, but since it now would have to contain the version number, we'd have to re-run alternatives on every update. I don't think that is acceptable.
Not sure that karma is working. I'm trying to give it a -1, but it doesn't seem to update. I'll try again...
One last time trying to post karma. Sorry for the noise...
This update has been obsoleted.
Hello, no problem for the noise. This is due to the horrible way of selecting the database that Bacula has. It depends on a library soname that no one provides so you need to rely on a symlink. Any tool (RPM, etc.) at build time flags that as unacceptable and you need workarounds. This is why the alternative is set with the unversioned library:
Alternatives is also configured to provide a default, so you should never ever run it again except at install time when selecting the database (please read the included README in the bacula-common package).
It works fine here in finding his libraries by just installing the packages: $ ls -algh /usr/lib64/libbaccats* lrwxrwxrwx. 1 root 13 May 14 09:35 /usr/lib64/libbaccats-9.0.7.so -> libbaccats.so -rwxr-xr-x. 1 root 27K Jun 11 12:49 /usr/lib64/libbaccats-mysql-9.0.7.so lrwxrwxrwx. 1 root 25 Jun 11 12:49 /usr/lib64/libbaccats-mysql.so -> libbaccats-mysql-9.0.7.so -rwxr-xr-x. 1 root 35K Jun 11 12:49 /usr/lib64/libbaccats-postgresql-9.0.7.so lrwxrwxrwx. 1 root 30 Jun 11 12:49 /usr/lib64/libbaccats-postgresql.so -> libbaccats-postgresql-9.0.7.so lrwxrwxrwx. 1 root 31 Jun 11 12:53 /usr/lib64/libbaccats.so -> /etc/alternatives/libbaccats.so -rwxr-xr-x. 1 root 24K Jun 11 12:49 /usr/lib64/libbaccats-sqlite3-9.0.7.so lrwxrwxrwx. 1 root 27 Jun 11 12:49 /usr/lib64/libbaccats-sqlite3.so -> libbaccats-sqlite3-9.0.7.so
Damn markdown, needs a cr before the code block:
I may not be using alternatives correctly. As per the readme, if I do:
alternatives --config libbaccats.so
then I only get:
What command did you use to create the link:
I see in your 'ls' that your libbaccats-9.0.7.so has a different date from your other files, so I'm wondering how it got created.
It's all in the README in the bacula-common package: /usr/share/doc/bacula-common/README.Redhat
The symlink gets created when you install the package. I guess you can just try removing everything and reinstalling. If you prefer to fix it manually:
And just select the number.
It does not work for me. I ran that exact command. All it did was create:
It did not create:
I'd like to request that you delete your "libbaccats-9.0.7.so -> libbaccats.so" symlink on your machine. Then run the command and see if "libbaccats-9.0.7.so -> libbaccats.so" is re-created for you.
If alternatives creates "libbaccats-9.0.7.so -> libbaccats.so" for you, then there is something that is keeping it from working properly for me. I'd like to figure out what that is...
You are right, that is a leftover from the previous attempts, and was recreated by ldconfig.
I restored the soname renaming patch:
https://src.fedoraproject.org/rpms/bacula/blob/master/f/bacula.spec#_44-49
And excluded the symlink in the %files section to workaround Fedora 28 builds adding the symlink anyway:
https://src.fedoraproject.org/rpms/bacula/blob/master/f/bacula.spec#_581-583
This fixes the library issues. I've created a separate update. Thanks for feedback!
New update: FEDORA-2018-f4cc6b44a5