update bacula-server 5.0.2 -> 5.0.3, Undefined symbol "ASN1_INTEGER_it

[Wesley Shields]

On Tue, Sep 21, 2010 at 09:48:50PM +0200, olli hauer wrote:
> On 2010-09-21 02:24, Wesley Shields wrote:
> > On Mon, Sep 20, 2010 at 07:39:58PM +0200, olli hauer wrote:
> >> On 2010-09-19 08:20, Per olof Ljungmark wrote:
> >>> FreeBSD 7.3-STABLE #0: Tue Sep  7 22:46:59 CEST 2010
> >>> peo at candyman.i.inter-sonic.com:/usr/obj/usr/src/sys/GENERIC  amd64
> >>>
> >>> Portupgrade of bacula-server 5.0.2 -> 5.0.3
> >>>
> >>> Starting bacula_fd.
> >>> /libexec/ld-elf.so.1: /usr/local/lib/libbac.so.5: Undefined symbol
> >>> "ASN1_INTEGER_it"
> >>> Starting bacula_sd.
> >>> Starting bacula_dir.
> >>>
> >>> If one deselects "OPENSSL" and recompile bacula-fd will start without
> >>> complaints.
> >>>
> >>> Is this a known issue with 5.0.3?
> >>
> >> No, can you provide me some more details.
> >>
> >> First make sure if you have both bacula-server and bacula-client installed
> >> on the same machine both are build with(out) ssl support.
> >>
> >> Both ports install libs with the same name to the same place, but if the
> >> client is build/installed first "with SSL support", and then the server
> >> without SSL support you can see exact the described issue.
> > 
> > Shouldn't the two ports register CONFLICTS then, thus making it
> > (normally) impossible for both to be installed on the same host?
> > 
> > -- WXS
> 
> At the moment I'm thinking about to install the client part within the
> server part as one port and mark bacula-client/bacula-server as conflict.

Should probably rename bacula-server to just "bacula" then as it will
include both the client and the server. And have separate ports for
server and client if that's all the user wants. Conflicts will have to
be set accordingly.

> Until now all my backup servers from different vendors doing the same
> and I see no reason to not backup the backup-server.
> 
> However this will only solve the shared lib problem in those two ports
> and there are some other slaves.
> 
> For the SSL thing a nice way would be a shared option like a electrical
> cross switch for such ports, on/off for all master/slaves not independent.
> 
> Maybe Dan (the maintainer) has some additional thoughts, so I set him on CC.

I'll leave all this up to you all. I trust the port is in good hands
between Dan and yourself. Thanks for working on it!

-- WXS