On 2017-12-24 09:37, Sven Hartge wrote:
Hmm. I will go out on a limb a bit here by saying the packaging seems
broken to me then.
But I am biased because I contribute to the Debian packaging and we
deliberately install those libraries into /usr/lib/bacula to avoid such
problems you have here. (Also the Debian Policy forbids the installation
of private libraries or plugins into the system library paths.)
ICBW of course but I think it's similar to /etc/packade.d situation
where you need to place user-modified files away from package manager's
control. Except in this case it's an .so, not .conf file.
There's nothing private about it, it is installed by the RPM that way.
Then it's modified by the admin to point to the non-stub .so for their
chosen DB backend. Exactly why SUSE restores *all* .so's to their
installed state on every RPM update is another question, but clearly it
is not compatible with the way bacula v.7+ handles its DB backends.
Dima
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
