[pkg-bacula-devel] [pkg-bacula-commits] [bacula] 01/01: Added "Muti-Arch: same" for bacula-director-common Added new debian version to debian/changelog

[Sven Hartge]

On 13.11.2017 00:29, Carsten Leonhardt wrote:
> Sven Hartge <sven at svenhartge.de> writes:
> 
>> Correct me, if I am wrong: since bacula-common containes shared objects in 
>> arch-unspecific paths, there is nothing we can do here, unless you want to 
>> move everything from /usr/lib/bacula/ to /usr/lib/$ARCH_TRIPLE/bacula/ to 
>> make bacula-common:$ARCH coinstallable. 
> 
> This sounds right, but I have to admit that I'm not too familiar with
> multi-arch specifics.

Neither am I, my "wisdom" comes from reading debian-devel and looking at
already packaged programs like pulseaudio to learn how they do things.

>> BTW: I have this in my ~/.gbp.conf:
>> This barks at me quite visibly if something is not like it should be.
> 
> I didn't build-test this change as it looked quite innocent on first sight.

Understandable, it's only a little meta-data change, isn't it? What
could it hurt? Well, package dependencies are tricky enough, adding
Multi-Arch into the mix just adds another dimension to consider.

Don't ask how many rebuilds I did when doing the multi-arch experiment.
(Answer: Far to many.)

>> I did a quick and very very dirty multi-arch PoC, see branch
>> "multi-arch". (I did this mainly to acquaint myself with the packaging
>> tools involved.)
>>
>> It builds, but is totally incorrect and should never be used directly.
>> It currently is not correctly multi-arch'ed and something with shlibs is
>> also wrong, mainly concerning the libbaccats*.so. My usage of dh-exec
>> needs checking.
>>
>> To use multi-arch with bacula the package bacula-common has to be
>> revamped, putting the libraries in its own package and the programs like
>> bsmtp, btraceback and the nagios_plugin in different one.
> 
> Ok, warning understood. So when we see a reason to need a multi-arch
> bacula, we have a starting point.

In the end is the question: Why? Bacula does not (yet) provide any
public libraries an external tool might want to interact with, so far
any libraries used by the tools comprising Bacula are private.

I can imagine only *one* highly niche scenario: If you have a 32bit
base-system with a 64bit kernel and more than 4GB RAM (like I do as my
main server) and want to have bacula-director access to more than 3GB
usable user-space memory, then you might want to install
bacula-director:amd64 while keeping everything else as 32bit.

But, and this is a very very big "bug", why would you want to keep
bacula-fd and maybe bacula-sd as 32bit then? If you already have a
multi-arch system, installing bacula-director:amd64 will pull soo mich
64bit-stuff into you system, also installing the rest of bacula as 64bit
does not make the situation any worse, AFAICS.

So for now the energy is better invested somewhere else, for example in
enabling hardening for all of bacula and not only bat.

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://lists.alioth.debian.org/pipermail/pkg-bacula-devel/attachments/20171113/1f9b5de0/attachment.sig>