[pkg-bacula-devel] Contribution
Mario Pranjic
mario at pranjic.no
Mon Sep 14 19:22:45 BST 2020
Hi,
Do other distros suffer the same issue with library name?
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?
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
And, at the same time, bacula-sd expects bacula-sd-cloud-driver-9.6.5.so
as filename.
I find it weird bearing in mind s3 driver here suppose to be solely for
Bacula purpose.
Best regards,
--*
Mario*
**
On 9/14/20 5:33 PM, Sven Hartge wrote:
> On 14.09.20 16:21, Carsten Leonhardt wrote:
>
>> Here starts one of our previous discussions about libs3:
>>
>> https://alioth-lists.debian.net/pipermail/pkg-bacula-devel/2020-June/003017.html
>>
>> I've sent an ITP for it:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962918
>>
>> Nobody complained there. The next step would be to create a package good
>> enough to upload to unstable, or at least experimental. Then the package
>> needs to clear the NEW-queue by getting approval by the FTP-masters.
> Some hints on libs3 for Bacula:
>
> I tried (privately) to package the library as private library for bacula
> in /usr/lib/bacula and /usr/include bacul instead of the normal
> /usr/lib/$(ARCH)/ location and change the name to something like
> "libbaculas3" but the build system and the sources themselves fought me
> every inch.
>
> In the end I gave up because I had reached my limit of knowledge of
> packaging libraries.
>
> Why a private library? Because the libs3 Bacula needs is a special fork
> by Bacula Systems and there is already a conflicting libs3 in Debian.
>
> Why the rename? To prevent any problems with the linker possibly finding
> two different libs3.so in the system, which would lead to problems.
>
> So getting the libs3 code pummeled into a shape to accept its new
> location and name would be a first step.
>
> Getting the Bacula source to accept that library is then the second hurdle.
>
> Grüße,
> Sven.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-bacula-devel/attachments/20200914/6261dc37/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-bacula-devel/attachments/20200914/6261dc37/attachment-0001.sig>
More information about the pkg-bacula-devel
mailing list