Helmut Grohne <hel...@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.