[pkg-bacula-devel] libs3

[Sven Hartge]

On 22.12.18 20:40, Carsten Leonhardt wrote:

> Bacula upstream has recently added support for S3 cloud storage using
> libs3. While trying to make use of it, Sven Hartge discovered that the
> packaged version of libs3 is not usable for us because Bacula needs a
> newer version, but also not too new... (he has the version we need here:
> https://salsa.debian.org/hartge-guest/libs3).
> 
> We also see that libs3 doesn't have any reverse depends in the official
> archive. Therefore I'd like to ask if you have any further plans with
> libs3 and if maybe you have an idea how we can proceed.

I think the main problem with libs3 is that the upstream developer
didn't to a proper numbered release since 2011. Since then it is just a
constant stream of commits and merges without any clear release schedule
or target to it.

Since libs3-2.0 it has gone through at least 4 semi-official but
unpredictable SO-name changes (from 2 to 3 to 4 to 4.1).

Kern Sibbald, the Bacula upstream, developed his S3 code in December
2016 and January 2017 and used the then current HEAD 06a4683 from
2016-12-14 to base his code on. Since then, libs3 changes considerably
and the current HEAD isn't even compatible with the code in Bacula any more.

Of course, one could argue that Bacula then has to change to be
compatible with the current HEAD of libs3, but looking at other
Distributions, like Centos7/RHEL7, shows the whole problem here. The
RHEL7 version of libs3 is only 10 days younger (from 2016-12-04), yet
its API and ABI are completely different.

Fedora on the other hand seems to follow the git HEAD quite fast,
creating even more fragmentation here.

Any other developer out there whose software might get packaged into
Debian could have chosen any other time to base their code on, making it
nearly impossible to decide which version to have in Debian, unless you
want to maintain multiple (which the RM and Security Team won't allow, I
am sure.)

After looking at all those developments with libs3 I am of the opinion
the library shouldn't even have a public library at all, it is just too
volatile.

How to proceed? I am not sure. Maybe any of you have an idea.

Grüße,
Sven.

-------------- 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/20181222/8f515d74/attachment-0001.sig>