Does georg or cvicentiu or danblack have any comments on this one?

Any comments from julien.fritsch?

I am planning to commit https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/2f183af990fbe1cfa8c343998c7640f45f45368b on upstream and to remove mariadb.pc from debian/libmariadbd-dev.install

mariadbd.pc for 10.6 sounds good to me

Filed PR to fix this for 10.6 in https://github.com/MariaDB/server/pull/1800

Thanks otto.

Example of recent user confusion on zulip.

On implementation we'd do a git mv on the file and adjust CMakeList.txt so it would be common to everyone. Might even be able to symlink in CMake too for everyone's convenience.

Another contributing factor is the description for the server side is so horrible (https://github.com/MariaDB/server/blob/10.6/support-files/mariadb.pc.in). We should be able to fix that in 10.2 as its only human readable stuff. Current its - ""MariaDB: a very fast and robust SQL database server", compared with the libmariadb client side "Description: MariaDB Connector/C dynamic library".

So suggested server description (compare to pkg-config --list-all - many of which are still poor, but you don't get two pc files for them):

Name: MariaDB server Plugins

Description: For all server plugins and extensions. For client library connections and client plugins use libmariadb.pc.

serg, ralf.gebhardt@mariadb.com what do you think of the name change/description change?

looking at other .pc files (on my gentoo), I'd suggest to rename to, say, mariadb-plugins.pc with

Name: MariaDB Server Plugins

Description: Plugin support for MariaDB Server

But it also means the content of this file might need some updating to match. For example, this could be wrong:

Libs: -L${libdir} @LIBS_FOR_CLIENTS@

Cflags: -I${includedir} @CFLAGS_FOR_CLIENTS@

But please make sure Amarok can link with embedded just as it was before. It seems to be relying on mariadb.pc sometimes

Yes, Amarok is to my knowledge the only consumer of mariadbd-dev (https://salsa.debian.org/qt-kde-team/extras/amarok/-/blob/master/debian/control#L55), but it is no longer in Debian (https://tracker.debian.org/pkg/amarok) as Amarok never migrated from Qt4 to Qt5.

I can't find that any other package would depend on libmariadbd (note the *d*).

$ apt-rdepends -r libmariadbd-dev

libmariadbd-dev

  Reverse Depends: default-libmysqld-dev (1.0.7)

default-libmysqld-dev

$ apt-cache rdepends --recurse libmariadbd-dev

libmariadbd-dev

Reverse Depends:

  default-libmysqld-dev

default-libmysqld-dev

Reverse Depends:

I did not understand the rationale of why call it mariadb-plugins.pc?

The main point is to teach devs that they should what is currently names libmariadb.pc instead of mariadb.pc. Adding mariadb-plugins.pc to the naming scheme does maybe not clarify it enough? Maybe if we have mariadb-client.pc and mariadb-plugin.pc it would be clear?

Still, personally I'd think mariadb.pc and mariadbd.pc is more clear, but I don't have a strong opinion.

Any comments from georg or julien.fritsch?

Is it OK if I proceed with my suggestions that

• libmariadb.pc = for client library (current status, continue for backwards compatibility)
• mariadb.pc = also client library use (new change, currently server)
• mariadbd.pc = server library (new filename)

Having mariadb.pc and mariadbd.pc as the final result is in my opinion aligned with what users expect, as these follow the binary and library names.

Won't it be strange to have libmariadb.pc and mariadbd.pc? I'd expect consistent names, like both starting with lib* or neither. So, just

• libmariadb.pc
• libmariadbd.pc

why mariadb.pc?

I suggested libmariadb.pc only for backwards compatibility. Sure, let's drop that. It is a config file so we don't need to consider backwards compatibility if you that sticks out.

Updated suggestion:

• mariadb.pc = client library use (new change, currently server)
• mariadbd.pc = server library (new filename)

The most common pattern is to use the library name without lib*, and I also personally think it looks cleaner.

/usr/lib/x86_64-linux-gnu/pkgconfig/atk-bridge-2.0.pc	libatk-bridge2.0-dev

/usr/lib/x86_64-linux-gnu/pkgconfig/atk.pc	libatk1.0-dev

/usr/lib/x86_64-linux-gnu/pkgconfig/atspi-2.pc	libatspi2.0-dev

/usr/lib/x86_64-linux-gnu/pkgconfig/javascriptcoregtk-4.0.pc	libjavascriptcoregtk-4.0-dev

/usr/lib/x86_64-linux-gnu/pkgconfig/libarchive.pc	libarchive-dev

/usr/lib/x86_64-linux-gnu/pkgconfig/ngspice.pc	libngspice0-dev

/usr/lib/x86_64-linux-gnu/pkgconfig/shibsp-lite.pc	libshibsp-dev

/usr/lib/x86_64-linux-gnu/pkgconfig/spoa-1.pc	libspoa-dev

/usr/lib/x86_64-linux-gnu/pkgconfig/webkit2gtk-4.0.pc	libwebkit2gtk-4.0-dev

/usr/lib/x86_64-linux-gnu/pkgconfig/webkit2gtk-web-extension-4.0.pc	libwebkit2gtk-4.0-dev

/usr/lib/x86_64-linux-gnu/pkgconfig/xmltooling-lite.pc	libxmltooling-dev

/usr/lib/x86_64-linux-gnu/pkgconfig/xmltooling.pc	libxmltooling-dev

the naming pattern with lib* is more common, but not overwhelmingly. About 1/3rd of all *.pc files have lib* prefix. On my laptop it's 136 lib*.pc files and 299 without lib*.

So I'd rather stick to the lib* old names for backward compatibility reason. I just don't see a good reason to break existing applications that check for libmariadb.pc.

I tried to research how much there might be downstream applications building with libmariadb.pc/mariadb.pc.

https://codesearch.debian.net/search?q=-llibmariadb&literal=1

• only 1 (qtbase-opensource-src-gles)

https://codesearch.debian.net/search?q=-lmariadb&literal=1&perpkg=1

• 10 packages (due to how codesearch.debian.net works, some results also have '-libmariadbclient'*

https://github.com/search?q=%22-lmysqlclient%22&type=code

• 41000 results

https://github.com/search?q=%22-lmariadbclient%22&type=code

• 400 results

https://github.com/search?q=%22-lmysql%22&type=code

• 1026 results

https://github.com/search?q=%22-lmariadb%22&type=code

• 912 results

https://github.com/search?q=%22-llibmysql%22&type=code

• 630 results

https://github.com/search?q=%22-llibmariadb%22&type=code

• 26 results

https://github.com/search?q=%22-llibmysqlclient%22&type=code

• 27 results

I tried to use data to make a good decision here, but I am not sure if I learned of the above anything. Sharing results of this check anyway.

This would clean up things as currently (including myself) it took a while to understand what is the diffrence between these two pc-files. Symlink can be provided to support older packages as this not for Windows.

serg Can you approve/merge https://github.com/MariaDB/server/pull/1800? It was been updated (long ago) to address your requests. It would be good timing to merge this now into 11.0.