Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.3(EOL), 10.4(EOL), 10.5
-
None
Description
Currently the setup of libmariadb, libmariadbclient and libmysqlclient is a mess. serg tried to fix it in commits b5ead3a658fe705ec64faa2450f6f5c3e2bf3482, 862fbc277c3e6396bdee44a54fc9769957b14ea9 and f7294f5b368116cc83f1d63cb0bcd4ad1cf30657. Then cvicentiu did 325718c996bceb1a3fa54453b54f8d1c2ccdee7d and then serg again f3b6c49f8f6326dfa6859f154d0069d5e735e7df.
I've attached the package listings for relevant lib* debs as of upstream 10.3 commit 1a62c8a3964 and what we have for the server 10.1 package and connector 2.3.x package in Debian officially now. The idea is that upstream 10.3 package listings should at least include everything we already provide in Debian's MariaDB 10.1 and Connector C packages. In addition we can have extra compatibility glue to replace MySQL in aggressive ways we are not allowed to do in official Debian repositories, but what we can do in our own MariaDB.org repo.
It is important to consider what is in Debian now, because those packages are tested extensively in real situations where lots of Debian packages are building against them. Debian users running Debian Stretch might want to use MariaDB 10.3 and upgrade from official Debian repos to MariaDB.org repos, and the upgrade path must work..
We also want to be as much as possible backwards compatible, both for people building new binaries against our libmariadb* libraries, and people running existing binaries and wanting to dynamically load .so files we ship.
I will try to fix this now.
Attachments
Issue Links
- is blocked by
-
CONC-304 Rename the static library to libmariadb.a and other libmariadb files in a consistent manner
- Closed
- relates to
-
MDEV-23538 Rename mariadb.pc to mariadbd.pc to avoid confusion
- Open