Re: [Bacula-users] Bacula 7.4.4 openSUSE packages: bad libbaccats symlink

2017-12-29 Thread Tilman Schmidt
Am 27.12.2017 um 11:00 schrieb Kern Sibbald: > As Dimitri points out, there should be no stub file.  It looks like SuSE > is trying to build Bacula the same way that it is done by Bareos, which > will not work. Thanks. Deleting the file /usr/lib64/libbaccats-stub-7.4.4.so solved the problem. It tu

Re: [Bacula-users] Bacula 7.4.4 openSUSE packages: bad libbaccats symlink

2017-12-27 Thread Kern Sibbald
Hello, As Dimitri points out, there should be no stub file.  It looks like SuSE is trying to build Bacula the same way that it is done by Bareos, which will not work. The only link you should have in the library directory should be something li

Re: [Bacula-users] Bacula 7.4.4 openSUSE packages: bad libbaccats symlink

2017-12-26 Thread Dimitri Maziuk
On 12/26/2017 06:20 AM, Tilman Schmidt wrote: > In fact, the /usr/lib64/libbaccats-stub-7.4.4.so library file seems to > be "asking" to be symlinked to libbaccats-7.4.4.so. If I rename that > file to libbaccats-stub-7.4.4.so.BAD and re-run ldconfig, it creates a > symlink libbaccats-7.4.4.so -> li

Re: [Bacula-users] Bacula 7.4.4 openSUSE packages: bad libbaccats symlink

2017-12-26 Thread Tilman Schmidt
Am 25.12.2017 um 20:08 schrieb Dimitri Maziuk: > On 2017-12-24 13:13, Tilman Schmidt wrote: >> Am 24.12.2017 um 18:43 schrieb Dimitri Maziuk: >>> Exactly why SUSE restores *all* .so's to their >>> installed state on every RPM update is another question, >> >> Actually it doesn't. It only happens wi

Re: [Bacula-users] Bacula 7.4.4 openSUSE packages: bad libbaccats symlink

2017-12-25 Thread Sven Hartge
On 24.12.2017 18:43, Dimitri Maziuk wrote: > There's nothing private about it, it is installed by the RPM that way. By "private" I meant: it isn't really a library to be used by external 3rd party tools like for example libcrypto or libmysqlclient is but rather a library only used internally by b

Re: [Bacula-users] Bacula 7.4.4 openSUSE packages: bad libbaccats symlink

2017-12-25 Thread Dimitri Maziuk
On 2017-12-24 13:13, Tilman Schmidt wrote: Am 24.12.2017 um 18:43 schrieb Dimitri Maziuk: Exactly why SUSE restores *all* .so's to their installed state on every RPM update is another question, Actually it doesn't. It only happens with libbaccats-7.4.4.so. Other alternative-symlinked .so-s in

Re: [Bacula-users] Bacula 7.4.4 openSUSE packages: bad libbaccats symlink

2017-12-24 Thread Tilman Schmidt
Am 24.12.2017 um 18:43 schrieb Dimitri Maziuk: > Exactly why SUSE restores *all* .so's to their > installed state on every RPM update is another question, Actually it doesn't. It only happens with libbaccats-7.4.4.so. Other alternative-symlinked .so-s in /usr/lib64 are left alone. And I don't thin

Re: [Bacula-users] Bacula 7.4.4 openSUSE packages: bad libbaccats symlink

2017-12-24 Thread Dimitri Maziuk
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. (A

Re: [Bacula-users] Bacula 7.4.4 openSUSE packages: bad libbaccats symlink

2017-12-24 Thread Sven Hartge
On 24.12.2017 14:34, Tilman Schmidt wrote: > Am 24.12.2017 um 13:51 schrieb Sven Hartge: >> On 20.12.2017 21:26, Tilman Schmidt wrote: >>> libbaccats.so -> /usr/lib64/libbaccats-mysql.so >>> libbaccats-7.4.4.so -> /usr/lib64/libbaccats-mysql-7.4.4.so >> >> Why are the libraries in the system libra

Re: [Bacula-users] Bacula 7.4.4 openSUSE packages: bad libbaccats symlink

2017-12-24 Thread Tilman Schmidt
Am 24.12.2017 um 13:51 schrieb Sven Hartge: > On 20.12.2017 21:26, Tilman Schmidt wrote: >> >> libbaccats.so -> /usr/lib64/libbaccats-mysql.so >> libbaccats-7.4.4.so -> /usr/lib64/libbaccats-mysql-7.4.4.so > > Why are the libraries in the system library path? They are private to > bacula and shoul

Re: [Bacula-users] Bacula 7.4.4 openSUSE packages: bad libbaccats symlink

2017-12-24 Thread Sven Hartge
On 20.12.2017 21:26, Tilman Schmidt wrote: > libbaccats.so -> /etc/alternatives/libbaccats.so > libbaccats-7.4.4.so -> /etc/alternatives/libbaccats-7.4.4.so > libbaccats-mysql.so -> libbaccats-mysql-7.4.4.so > libbaccats-stub.so -> libbaccats-stub-7.4.4.so > > which allows the symlinks in /etc/al

Re: [Bacula-users] Bacula 7.4.4 openSUSE packages: bad libbaccats symlink

2017-12-24 Thread Tilman Schmidt
Die 20.12.2017 hora 21:26 scripsi: > After installation of the bacula-director > and bacula-mysql packages, the symlinks for the libbaccats library in > /usr/lib64 look like this: > > libbaccats.so -> /etc/alternatives/libbaccats.so > libbaccats-mysql.so -> libbaccats-mysql-7.4.4.so > libbaccats-s

Re: [Bacula-users] Bacula 7.4.4 openSUSE packages: bad libbaccats symlink

2017-12-24 Thread Tilman Schmidt
Die 20.12.2017 hora 21:26 scripsi: > I've recently upgraded Bacula on an openSUSE Leap 42.3 system from > release 5.2.13 to the release 7.4.4 packages from > https://build.opensuse.org/package/show/home%3AXimi1970%3AopenSUSE%3AExtra/bacula > [...] After installation of the bacula-director > and bac

[Bacula-users] Bacula 7.4.4 openSUSE packages: bad libbaccats symlink

2017-12-20 Thread Tilman Schmidt
Hello list, I've recently upgraded Bacula on an openSUSE Leap 42.3 system from release 5.2.13 to the release 7.4.4 packages from https://build.opensuse.org/package/show/home%3AXimi1970%3AopenSUSE%3AExtra/bacula I hope it's not offtopic here to ask about a problem that looks like specific to that p