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

[Carsten Leonhardt]

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.

> Question is: why would anyone do this? Have a 32bit FD on the same machine 
> as a 64bit director?

I can't think of a reason, and up to now nobody complained that it
doesn't work...

> 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.

> 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.

Carsten