[debian-mysql] Bug#842454: Bug#842454: Bug#842454: default-libmysqlclient-dev is unsatisfiable for cross builds

[Kristian Nielsen]

Otto Kekäläinen <otto at debian.org> writes:

> 2016-10-30 1:45 GMT+03:00 Kristian Nielsen <knielsen at knielsen-hq.org>:

>> Maybe something like this is needed on the cmake command?
>>
>>   -DINSTALL_PLUGINDIR=/usr/lib/x86_64-linux-gnu/mysql/lib18/plugin

>> (This build option seems to be shared between the server plugins and the
>> client plugins, which seems a bit of a mess, and might require a separate
>> build for the server package and the client library package - but maybe that
>> is already the case anyway?)
>
> I tried this avenue but indeed the PLUGINDIR parameter then also
> changes where all the server plugins (TokuDB, Spider etc) are
> installed, so that is not an option.
>
> Can you Kristian help us introduce in the makefiles a new parameter
> CLIENTPLUGINDIR?

Something like the attached patch could work.

But what is the problem with putting the server plugins into an
arch-dependent location as well? I discussed this briefly with Serg on IRC,
he also suggested that. It seems simpler if all the plugins are in the same
place, and there does not seem to be any harm in having server plugins with
arch-dependent paths as well.

> Or what if we keep the PLUGINDIR=lib/mysql/plugin but then in a later
> stage in the rules file move the two client plugins?
>   mv lib/mysql/plugin/dialog.so  lib/$(DEB_HOST_MULTIARCH)/mariadb-lib18/plugin
>   mv lib/mysql/plugin/mysql_clear_password.so
> lib/$(DEB_HOST_MULTIARCH)/mariadb-lib18/plugin

The CMake option is not so much about where `make install` puts the files,
but about where the server and client library looks to find the plugins at
runtime. Otherwise we would need --plugindir options in my.cnf.

> (For reference, in mariadb-connector-c shared libs are built with
> 'dh_makeshlibs -X/mariadb/plugin/' and installed to
> usr/lib/*/mariadb/plugin/*.so, and it has 'Multi-Arch: same' - see
> https://anonscm.debian.org/cgit/pkg-mysql/mariadb-client-lgpl.git/tree/debian)

So with usr/lib/*/ you mean for example usr/lib/x86_64-linux-gnu/, right?

Seems just one more reason to do the same for the client library built from
the 10.0 server sources. Wouldn't just doing this solve the problem?

I did not so far get a definite answer as to whether client plugins are
compatible with all major library versions or just the one they were built
against. Since MariaDB never changed the major library version so far, it
may not have a meaningful answer defined. But again, it seems safe enough to
just include the major version number in the plugin path. It does not hurt,
it satisfies Debian policy, and it makes things simpler if in the future a
major version .so bump happens.

 - Kristian.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmake_install_clientplugindir.patch
Type: text/x-diff
Size: 6879 bytes
Desc: Patch to add -DINSTALL_CLIENTPLUGINDIR cmake option
URL: <http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/attachments/20161110/29bdb57b/attachment.patch>