[Pkg-firebird-general] Bug#269750: linking fun with libfbembeded and libfbclient

[Remco Seesink]

--Signature=_Wed__15_Sep_2004_00_31_16_+0200_qwfBmirXdhnAd7vB
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Hi Damyan, Daniel, Mark, others.

Sorry that I haven't had time to reply to the suggestions earlier. They are
aprecciated! We are really talking about bug #269471 here and a possible
solution is suggested in bug #269750, so Daniel could be right that #269750
is not a bug. This depends on the solution of #269471.

On Tue, 14 Sep 2004 16:43:38 +0300
Damyan Ivanov <divanov@creditreform.bg> wrote:
> I see two resolutions for this.
> 
> 1) Force php4-interbase and IBPerl to link with libfbclient as suggested 
> by Mark O'Donohue (and not libgds). This way they can both depend and 
> build-depend on libfirebird2 and always link against libfbclient 
> (available for both super and classic)

Well, this will still cause problems for people compiling their own whatever
and link them to libfbembed and load it into apache or some other similar
situation. It could also have problems with binaries from non debian origin.

> 2) Rename both libfbembed and libfbclient to libfirebird and link 
> php4-interbase, IBPerl and any other such modules (python-firebird, 
> anyone?) with it. This way, any package depending on "some firebird 
> client library" will get the same - the one currently installed on the 
> system.

This has the problem that it is non (upstream) standard, so people compiling
stuff from source using these libs will have problems. This looks like the
previous situation upstream migrated away from.

> I realize that 2) is rather intrusive change. I don't see any problems 
> with it, however. The reason why I try to avoid 1) is that if my webapp 
> uses libfbclient to connect to the local database, it will use a 
> connection through lo network interface, posing performance penalty.

And you suggested a 3th option in bug #251458:
-------------------------------------------------------
>Can the alternative system be used for this? I.e. we have two 
>alternatives for libfirebird2 - "-classic" and "-super". They can't both 
>be installed simultaneously, and they both provide the same API.
>
>So php4-interbase can depend (and build-depend) on libfirebird2, which 
>is provided by either libfirebird2-classic or libfirebird2-super.
>
>The key point is to make php4-interbase link agains the "alternative 
>alias". Currently, 3.6.1 is linked against libgds (provided by 
>libfirebird1), which became a compatibility symlink in libfirebird2. 
>This is just fine, but I can't imagine how to do it when building 
>against libfirebird2 :-|
>
>I am not sure if "alternative" has to be replaced with "diversion" 
>above. I am not fluent with both alternative and diversion systems.

I am not fluent in both the alternative and diversion systems either. First
impression is that is is not meant for this, but it might be genius if the
compile problem is fixed.

The 4th solution would be 2 php4-interbase packages. 1 for super 1 for
classic. This just feels wrong and ugly, but it will work.

I have a feeling that there must have been similar situations in the past and
that I don't see the obvious way out of here. Current situation for sarge seems
fine but we have to migrate from libgds.so eventually. Maybe upstream thought
this out when they changed from libgds.so to libfbembed and libfbclient.

Mark, any suggestions?

Cheers,
Remco.

--Signature=_Wed__15_Sep_2004_00_31_16_+0200_qwfBmirXdhnAd7vB
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBR3E6VYMI95VPXscRApBPAJ986WRCnuHiE+GoNtjGOQUtd7ro1ACfZssO
MYu+4ncyqekDq+6yc2Ye9Jg=
=H1Pi
-----END PGP SIGNATURE-----

--Signature=_Wed__15_Sep_2004_00_31_16_+0200_qwfBmirXdhnAd7vB--