Sergei's original thoughts on this:

• a separate package with symlinks, like mariadb-server-compat, mariadb-client-compat (using debian names), mariadb-server-core-compat, etc
  problem: too many new packages (almost 2x). confusing?
• one package mariadb-compat with all symlinks
  problem: it will require all mariadb packages, one will have to install everything.
• one package that doesn't include symlinks, but creates them in the postinst script, looking at what other mariadb* packages are installed
  problem: fragile, depends on installation order
• one package that installs, say, /etc/mariadb-create-compatibility-symlinks.flag and every package creates symlinks in postinst if the flag is present
  or may be a tool /usr/bin/mariadb-create-compatibility-symlinks does it if the flag is set, and postinst scripts invoke it, so that the user could regenerate symlinks without reinstalling

Several discussions with subject matter experts for Debian and RedHat packaging have happened. It is looking like the first option is probably the best. RedHat mentioned that they don't like having packages that have files generated by scripts. Doing so makes it difficult to trace which file came from which package, and there are other potential issues during upgrades or switching MariaDB <-> MySQL.

Debian mentioned that you can't have a package install symlinks that link to missing files with Debian packages, so that rules out the single package option.

If distros dislike dynamically created symlinks, then let's implement the first option, indeed.

After looking what was generated with:

diff --git a/cmake/mysql_add_executable.cmake b/cmake/mysql_add_executable.cmake

index 06bdfce14de..09623513a05 100644

--- a/cmake/mysql_add_executable.cmake

+++ b/cmake/mysql_add_executable.cmake

@@ -106,7 +106,7 @@ FUNCTION (MYSQL_ADD_EXECUTABLE)

          ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${link}

          DESTINATION

          ${ARG_DESTINATION}

-         COMPONENT ${COMP})

+         COMPONENT ${COMP}-symlinks)

     ELSE()

       # Windows note:

The list of packages for symlinks is just:

• Server
• Client
• Test
• backup
• rocksdb-engine

Doing the same for scripts:

diff --git a/scripts/CMakeLists.txt b/scripts/CMakeLists.txt

index 9eec793c9fb..416d4a68415 100644

--- a/scripts/CMakeLists.txt

+++ b/scripts/CMakeLists.txt

@@ -373,7 +373,7 @@ ELSE()

     INSTALL_SCRIPT(

       ${CMAKE_CURRENT_BINARY_DIR}/${file}

       DESTINATION ${INSTALL_BINDIR}

-      COMPONENT ${${file}_COMPONENT}

+      COMPONENT ${${file}_COMPONENT}-symlinks

     )

     # make scripts executable in build dir

Adds "Development" to the list.

bb-10.11-danielblack-MDEV-30203-pkgtest-rpm-symlink-packages, which generates symlink packages.

note backup is mariabackup -> mariadb-backup which is old compat and could be dropped?

Removing last bit of mysql references in MDEV-30275 needed for compat packages to be truly optional.

https://github.com/MariaDB/server/pull/2390

So the update plan is:

*-compat, both RPM and Debs are an optional package containing the mysql compatibility links. The man pages thanks to Sergei are the man page forms of links in a man page format.

The client or server packages in 11.0 are recommending the compat package that provides links to executables the the client/server package.

Some small cleanups putting man pages into the right packages like s3 and rocksdb.

bb-11.0-danielblack-preview-MDEV-30203-fix updates the handling of scripts.

https://buildbot.mariadb.org/#/grid?branch=bb-11.0-danielblack-preview-MDEV-30203-fix-pkgtest (same branch different name) generated RPMs in https://ci.mariadb.org/31771/ for testing.

I have no objections against pushing 1e6e88fc073e3a766ca in 11.0 and releasing with 11.0.1.

It appears that on systems which we currently release, the packages with symlinks (mariadb-server-compat and mariadb-client-compat) are installed by default, so hopefully the inconvenience to the users is minimal at this point. Still, it would be very good if users tried it out in their environments and reported issues they observe.

On debs the packages can be opted out.
Upd: as shown in the comment below, for RPMs they can be opted out too, except for older versions which don't support weak dependencies (e.g. RHEL 7).

It's not clear how distributions are going to handle it when the time comes – will they follow the same pattern and build separate packages, or will they do it some other way, but it is a problem for the future.

Upd:
In regard to RPMs, there is a problem with repository creation, which affected the testing and may affect the release as well. We may have to upgrade createrepo before the release for the recommended packages to work, but it is outside the scope of this task.

One can opt out with rpms too, we do it in buildbot with

sudo dnf --setopt=install_weak_deps=False instal ...

I'll push 9656356b5500 instead which differs from 1e6e88fc073e3a766ca in corrected man pages for mariadb*embedded tools

Thanks serg, elenst for fixes and testing.

createrepo with the --setopt=install_weak_deps=False is sufficient for an install base on ci.mariadb.org using createrepo in its rpm artifacts.

[root@citest-1 dan]# cat /etc/yum.repos.d/MariaDB*.repo 

[MariaDB-11.0]

name=MariaDB bb 11.0

baseurl=https://ci.mariadb.org/32474/amd64-rhel-8-rpm-autobake/rpms

gpgcheck=0

module_hotfixes=1

enabled=1

[root@citest-1 dan]# dnf --setopt=install_weak_deps=False MariaDB-client

Updating Subscription Management repositories.

No such command: MariaDB-client. Please use /bin/dnf --help

It could be a DNF plugin command, try: "dnf install 'dnf-command(MariaDB-client)'"

[root@citest-1 dan]# dnf --setopt=install_weak_deps=False install MariaDB-client

Updating Subscription Management repositories.

Last metadata expiration check: 0:45:03 ago on Sun 12 Feb 2023 11:56:30 PM EST.

Dependencies resolved.

================================================================================================================================

 Package                     Arch        Version                                    Repository                             Size

================================================================================================================================

Installing:

 MariaDB-client              x86_64      11.0.1-1.el8                               MariaDB-11.0                           16 M

Installing dependencies:

 MariaDB-common              x86_64      11.0.1-1.el8                               MariaDB-11.0                           88 k

 MariaDB-shared              x86_64      11.0.1-1.el8                               MariaDB-11.0                          119 k

...

(and no MariaDB-client-compat)

danblack,

What createrepo does on ci.mariadb.org is unfortunately irrelevant, it is not the same repo as we release. Same faulty assumption was made during testing, that all of them are the same.

If you look for example into https://ci.mariadb.org/32167/amd64-rhel-9-rpm-autobake/rpms/ which built from the release revision of 10.9, specifically file https://ci.mariadb.org/32167/amd64-rhel-9-rpm-autobake/rpms/repodata/44f64647a2f1d8d1f8d56a60ddefe5ad1acfab10018461996efbc7d5a438d517-primary.xml.gz, it has these blocks:

    <rpm:recommends>

      <rpm:entry name="jemalloc"/>

    </rpm:recommends>

...

    <rpm:recommends>

      <rpm:entry name="pv"/>

    </rpm:recommends>

but the file in the actual release repo http://mirror.mariadb.org/yum/10.9/rhel9-amd64/repodata/8a22a2af34cc4f0b3fbd7c61de213cd637f1e45af18f4de1afbcca426943ca46-primary.xml.gz does not have them.

The release build environment has 0.10.3 which is pretty old, it may be not aware of recommends dependencies same way as old rpm does not know about it.

Same is happening with the new compat packages, except that we don't have a release-like repo yet.
I've just created a repo here https://buildbot.mariadb.net/archive/pack/bb-11.0-all-builders/build-53221/kvm-rpm-rhel9-amd64/rpms/ , I think I am using the same createrepo version as the release process does. As you can see, compat packages are not pulled from there.