Re: Packaging Question
Christian Hammers <ch@westend.com> writes:
> Hello Andreas
>
> On Sun, 21.05.00 16:33 +0200, Andreas Rottmann wrote:
> > sponsor). The package is a C++ SQL CLI (Call Level Interface) library
> > called GQL. See http://GQL.sourceforge.net for more information.
> I.e. it's a programming API for using several databases with the same
> functions? Sounds nice. As I once wrote such a thing in C and currently
> am the mysql maintainer I would like to sponsor you.
>
Thanks.
Yes, it is - something I found lacking (at least in OSS). Yes, there
is libodbc++, but that works via ODBC, which is hard to install and
get working - I tried and failed. That gave me the "kick" to start
with GQL.
I'am sure your glad to hear that a GQL MySQL driver exists (if you
didn't see it on the HP yet) ;-)
> > W: libgql0-driver-pg: non-dev-pkg-with-shlib-symlink usr/lib/gql/drivers/libgql-pg.so.0.0.0 usr/lib/gql/drivers/libgql-pg.so
> The reason is that the simlink called *.so is normally not necessary as
> binaries have the complete name (.so.1.2.3) compiled in and only the compiler
> needs the pure .so file.
> I don't know how loading the drivers in your package works - if you like
> to just load mysql.so and are sure that replacing this file with further
> versions does *NOT* lead to problems (i.e. rendering version numbers useless)
> *then* it's ok to include it in the drivers package.
>
I load them at runtime using the functions provided from
libglib. There is a function in libglib that builds the library name,
to avoid hard-coding it in user code and causing incompatibilies:
---file: driver-manager.cc---
filename = g_module_build_path(path.c_str(), ("gql-" + id).c_str());
module = g_module_open(filename, G_MODULE_BIND_LAZY);
-----------------------------
This results for 'path == "/usr/lib/gql/drivers"' and 'id == "mysql"'
in the name "/usr/lib/gql/drivers/libgql-mysql.so" - at least on
Linux, the name on other platforms may vary (libglib support Win32 for
instance, AFAIK). Thus I have some options providing
interface-compatibilty between libgql and the driver packages:
a) Mangle the version info into the file name, and ensure the driver
is installed under that name. This is not very clever, since it
establishes dependency between code and platform 'habits'. (Version
info could be make the filename too long on some platforms, or doesn't
give a valid filename at all).
b) Leave it that way and add code in the loader + driver to exchange
interface versions and let the load fail if not compatible.
c) Leave it that way and depend on the Debian package system to ensure
the versions match. I think this is what is implemented right now:
libgql0-driver-* depend all on (libgql0 = source_version). So you
can't install drivers that have not the same version as the library.
> Else this link belongs to the -dev package which has of course to depend on
> the driver package.
>
It doesn't make sense there, since programs will _never_ link against
a driver - this is the whole point of GQL!
MfG, Andi
--
Andreas Rottmann (Dru@ICQ, 54523380@ICQ)
Pfeilgasse 4-6/725, A-1080 Wien, Austria, Europe
http://www.penguinpowered.com/~andy/
mailto:a.rottmann@gmx.at
[one of 78,35% Austrians who didn´t vote for Haider!]
Reply to: