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

[Kristian Nielsen]

Helmut Grohne <helmut at subdivi.de> writes:

> | dpkg: error processing archive /tmp/apt-dpkg-install-qGtx4F/3-libmariadbclient18_10.0.27-2_i386.deb (--unpack):
> |  trying to overwrite shared '/usr/lib/mysql/plugin/dialog.so', which is different from other instances of package libmariadbclient18:i386

> The presence of Multi-Arch: same indicates that the package can be
> unpacked multiple times for different architectures at the same time.
> Their files may overlap if and only if the content is equal for
> overlapping files. Unfortunately, that's not the case for
> /usr/lib/mysql/plugin/dialog.so, so Multi-Arch: same is wrong here.

> I have no clue what these plugins are about and why they reside in
> libmariadbclient18. So cannot provide a patch here. To fix this

So these are authentication plugins for the client library. The server can
be configured to use different authentication methods (pam, two-factor,
whatever). An authentication method can require a plugin to be available on
the client side, and it will be loaded by the client library if available.

I guess it might be similar to nss plugins for glibc? But they seem to be
named with the libc version number, like on my jessie system:

-rw-r--r-- 1 root root 22100 Sep  5 08:22 /lib/i386-linux-gnu/i686/cmov/libnss_dns-2.19.so
lrwxrwxrwx 1 root root    18 Sep  5 08:22 /lib/i386-linux-gnu/i686/cmov/libnss_dns.so.2 -> libnss_dns-2.19.so

Clearly, these libmariadb plugins need to have an arch-dependent path. I
suppose they also need a path that includes the major .so version number of
the libmariadbclient.

Maybe something like this is needed on the cmake command?

  -DINSTALL_PLUGINDIR=/usr/lib/x86_64-linux-gnu/mysql/lib18/plugin

That build option seems to be what determines where the client library will
look for its 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?)

> In any case, the presence of these plugins violates the Debian policy
> section 8.2:
>
> | If your package contains files whose names do not change with each
> | change in the library shared object version, you must not put them in
> | the shared library package.

Presumably, it is enough that the full path name is different? So that
putting the shared object version in the directory path is sufficient? I do
not think the client library currently supports loading of modules with a
different name, eg. dialog-18.so or dialog.so.18.

Alternatively, I suppose these plugins should be put into a separate
libmariadb-plugins package or something (but they would still need an
arch-dependent path for multilib support).

Hope this helps,

 - Kristian.