MDEV-38532 Debian packages are missing many server include headers, such as handler.h #4547
Conversation
…uch as handler.h include headers needed to build plugins, same as in RPMs
|
|
| usr/include/mariadb/mysql_com.h | ||
| usr/include/mariadb/mysql_version.h | ||
| usr/include/mariadb/mysqld_error.h | ||
| usr/include/mariadb/server/* |
There was a problem hiding this comment.
Isn't the request MDEV-38532 about the server and the package to update is libmaraidbd-dev.install?
There was a problem hiding this comment.
They are in MariaDB-devel package (for example, see this)
So I thought an appropriate Debian counterpart is libmariadb-dev
There was a problem hiding this comment.
The libmariadb-dev is intended to be used by C/C++ programs to have the connector client to connect to the server, running from e.g. mariadb-server-core package. The libmariadbd-dev is intended to be used by C/C++ programs that want to embed the server and not depend on a external running MariaDB server at all.
The emdedded server libmariadbd.so.19 is shipped in libmariadbd19t64. I didn't spot that the RPM would have any libmariadbd.so.19 at all, but I am not sure how to browse CentOS package lists.
My guess is that having those server headers in the client library MariaDB-devel is an oversight and nobody is probably using them? Aligning the .deb contents with a .rpm contents is a good principle in general, but only if it is verified that the rpm contents is really intentional and there is a design and real usage behind it.
There was a problem hiding this comment.
I don't have a ready-to-use link that shows the file content of our (not distro) packages, but we put libmariadbd.so.19 in MariaDB-server. I agree that it's not perfect.
libmariadbd-dev indeed is intended to be used by programs that want to embed the server, not for plugin development, so it's not a good choice.
libmariadb-dev is not ideal either, but it's consistent with RPM and it's where these files were historically added — yes, they were added by a request from Slackware MariaDB maintainer, see MDEV-207, commit 9152701
There was a problem hiding this comment.
Hmm.. if the goal is to support plugin/storage engine development, should we have a new mariadb-plugin-dev package? That was suggested in https://bugs.launchpad.net/maria/+bug/470580 and kind of make sense.
There was a problem hiding this comment.
Technically, yes. It's a tradeoff between the number of packages and packages really being "one-purpose" only.
At one extreme there's just one package with everything. At the other — basically every executable and script can be in a separate package (users of mariadb-dump don't necessarily want or need mariadb-access), and libmariadbclient.a can be in a separate package libmariadb-dev-static.
In fact, I'd love to remove perl-dbi dependency from mariadb-client, most users don't need it. What do you think?
Could be a separate package mariadb-client-perl.
But here, considering it's only 7.5M of headers with absolutely no external dependencies, I'd prefer not to increase the number of packages for that. Note that libmariadbclient.a is 19M, but it's not in a separate package.
There was a problem hiding this comment.
Perl dependencies were laxed in Debian in https://salsa.debian.org/mariadb-team/mariadb-server/-/commit/87e8d8a86099d3d7aee68a14a1de2a70a9db35cc
There is a lot of improvements done in Debian that could be adopted in upstream MariaDB as well (https://salsa.debian.org/mariadb-team/mariadb-server/-/commits/debian/latest).
|
Would it be better to put this fix into |
|
It was in RPM for years, I'm just syncing two distribution formats, not introducing a really new feature. |
github-actions
bot
added
the
External Contribution
ottok
left a comment
ottok
left a comment
There was a problem hiding this comment.
It was in RPM for years, I'm just syncing two distribution formats, not introducing a really new feature.
I am approving this now based on above. I don't think this is a good long-term solution and we are basically just copying over to .deb the hack done in .rpm instead of doing it properly and having a holistic and documented plan on how to actually develop and build plugins for MariaDB without having to build the entire server. Hopefully that comes later.
include headers needed to build plugins, same as in RPMs