[pkg-bacula-devel] Contribution

Sven Hartge sven at svenhartge.de
Mon Sep 14 20:16:55 BST 2020


[Please don't top post. Thank you.]

Um 20:22 Uhr am 14.09.20 schrieb Mario Pranjic:

> Do other distros suffer the same issue with library name?
 
That issue is specific to Debian. I will explain more further down.

> I still struggle to fully understand relation between Bacula community
> and Bacula Enterprise. Where does the code originate from? Or we are
> talking about two separate branches here and independent roadmaps?

libs3 originates from https://github.com/bji/libs3 and is a third party
library for Amazon S3 acccess. Bacula Systems originally used the libs3
git HEAD version from December 2016 when then developed the (then)
proprietary cloud driver for Bacula Enterprise.

3 years later the cloud driver is fully open-sourced and integrated into
the Bacula community version.

It was soon discovered that libs3 is a bit of a mess, because it never
really got a stable API and even slightly different versions are
incompatible with each other, making using and packaging it very
difficult. In addition to that the last offical release of libs3 was in
2011, which is the version currently in Debian.

Unfortunately libs3 is very much abandoned by its authors and does not
even compile without errors with anything newer than GCC8 without heavy
patching. (And my personal opinion is that libs3 is a security breach
wating to happen.)

> I managed to build s3 library yesterday on Debian 10 (system is running
> Bacula 9.6.5 from backports) and now I am figuring it out how to call it
> from bacula-sd.
> I began here: https://www.bacula.org/bacula-release-9-6-5/
> 
> Build ends up with structure:
> 
> .
> ├── DEBIAN
> │   ├── control
> │   ├── postinst
> │   └── shlibs
> └── usr
>     ├── bin
>     │   └── s3
>     ├── lib
>     │   ├── libs3.so -> libs3.so.4
>     │   ├── libs3.so.4 -> libs3.so.4.1.bac
>     │   └── libs3.so.4.1.bac
>     └── share
>         └── doc
>             └── libs3
>                 ├── changelog.Debian.gz
>                 ├── changelog.gz
>                 └── copyright
> 
> build ends up with two packages:
> -rw-r--r-- 1 root root 54992 Sep 14 20:11 libs3_4.1.bac_amd64.deb
> -rw-r--r-- 1 root root 55848 Sep 14 20:11 libs3-dev_4.1.bac_amd64.deb

This is all well and good but as said above, there is already a different
version of libs3 in Debian. The one for Bacula can't be concurrently
installed with the existing one and also because of the problems with the
API stability lined out above, it shouldn't.

The only possibility of getting Baculas own libs3-fork into Debian is by
making it a private library, in contrast to the public system library you
created above.

Which means

1) installing into /usr/lib/bacula and /usr/include/bacula
2) changing the library name from libs3 to something different so the
dynamic linker does not get confused

or

2) changing it to a static library that is linked into the cloud-driver at
compile time.

> And, at the same time, bacula-sd expects bacula-sd-cloud-driver-9.6.5.so
> as filename.

That is OK, this is correct.

> I find it weird bearing in mind s3 driver here suppose to be solely for
> Bacula purpose.

Please explain.

Grüße,
Sven.




More information about the pkg-bacula-devel mailing list