Salsa testing project is currently located in:
https://salsa.debian.org/illuusio/mariadb-server/-/tree/10.8-MDEV-27033-lintian

Where 10.8 is getting build with Salsa-ci. There is plenty of minor and major problems to be solved:

• Lintian test is still full of problems which makes real problem spotting hard. They need to be addressed or turned of it they are false-positives/not bugs this make package hopefully more future-proof
• Autopkg test is not working currently and it's developed in (https://salsa.debian.org/illuusio/mariadb-server/-/tree/10.8-MDEV-27033-autopkg)
• Update to from older MariaDB 10.x version does not work
• New compression provider (bzip2, lzma, lzo, lz4 and snappy) are not linked against libc as they don't have any symbols from there. This leads problems with lintian and test will need to be turned of for a while and work with upstream lintian how to make them work (do there need some work-a-round like others)
• Here and there is small rust which needs to be addressed

Package needs to be building against Salsa-CI after real version remove can happen so it can be tested and verified it 'works' as old one. There is many small branches that is need to be upstream and discussed after Salsa-CI is happy with 10.8 or in near future 10.9.

Before upstreaming work there is need to solve couple show stoppers on 10.8 after that things should be upstreamed and delvelopment branch rebased to 10.9 on Salsa:

1. Autopkg mysql testsuite is not working (I have to find which commit breaks it as before updating tree last week it was green) breaking test is `main.group_min_max`and it can be found on this link https://salsa.debian.org/illuusio/mariadb-server/-/jobs/2485496/raw
2. Breaking test fails because `mariadb.pc` conflicts with two packages. Again I have to dig through GIT history to see what have been changed
3. blhc test fails as there is no build-file available on build and that needs to be checked.

When everything than Lintian (which can't be green at the moment as there is some work on Lintian needed) is green then we can assume that version number work can be started on Salsa-CI with 10.9 branch.

Reasoning for this kind on big change are:

1. Currently every major MariaDB release (upcoming 10.9, newz 10.10) there is need to tune Debian control file Conflicts, Breaks and other packaging to remove all the older versions of MariaDB (like mariadb_server_10.3, mariadb_server_10.4 and etc). This necessary as most of files are updated and every release expect that all files are up-to-date or there is big possibility that something get broken as some packages Conflict, Break or other is not updated. This kind of 'wearing' has already happen and will likely to be happen in future.
2. As mentioned in point 1. it's also impossible currently have to separated versions of MariaDB installed. This was motivation this kind of packaging numbering. It more necesery to get more precises numbering for libmariadb (like if there 3.0.2 and 3.1.0) should be named libmariadb30 and mariadb31. So external applications that rely on some library does not get broken
3. Time has passed and containers, virtual machines and other virtualization systems has surpassed need for same package in same system. If you need this kind of setup it's easier to use MariaDB containerized or with virtualization.
4. Current packaging causes `depency hell` for humans and all the other major distributions only have one MariaDB package and without major version number in name. RHEL rpm is just `mariadb` same goes with SuSE. So if some package is not updated human can't spot easily which old MariaDB version is causing problem.
5. Maintainers are happier. Currently every change that is made for example in 10.5 Debian postint script (which is runned after server is installed) is named in 10.5 `mariadb-server-10.5.postinst` has to be manually patched upstream as in 10.9 name is `mariadb-server-10.9.postinst`. It's not biggie but as changes are not 'big' enough to justification of name change.
6. Cleaner code is more contributors. Cleaner code brings more contributors. Currently Debian packaging doe this way is bit messy. There is no show stopper why it can't be done this way in future but then in 10.1500 Debian control file starts to be very very huge and there is mainly nothing more than Conflicts, Breaks and other package sanitation stuff

This is good time to make this kind of change. It's big but it should not show to user otherwise than MariaDB packages are easier to manage.

Note this will not affect the version in filenames, just the needless major version in some of the mariadb-client-* and mariadb-server-* packages:

mariadb-client-10.6_10.6.7+maria~stretch_arm64.deb	2.0 MiB	2022-Feb-12 00:33

mariadb-client-10.6_10.6.7+maria~stretch_i386.deb	2.1 MiB	2022-Feb-12 00:35

mariadb-client-10.6_10.6.7+maria~stretch_ppc64e..>	2.3 MiB	2022-Feb-12 00:31

...

mariadb-client_10.6.4+maria~stretch_all.deb	2.6 KiB	2021-Aug-04 16:18

mariadb-client_10.6.5+maria~bullseye_all.deb	2.6 KiB	2021-Nov-06 18:29

mariadb-client_10.6.5+maria~buster_all.deb	2.6 KiB	2021-Nov-06 18:23

...

mariadb-server-10.6_10.6.5+maria~buster_amd64.deb	3.2 MiB	2021-Nov-06 18:22

mariadb-server-10.6_10.6.5+maria~buster_arm64.deb	3.0 MiB	2021-Nov-06 18:28

mariadb-server-10.6_10.6.5+maria~buster_ppc64el..>	3.2 MiB	2021-Nov-06 18:25

...

mariadb-server-core-10.6_10.6.4+maria~stretch_p..>	6.3 MiB	2021-Aug-04 16:20

mariadb-server-core-10.6_10.6.5+maria~bullseye_..>	6.7 MiB	2021-Nov-06 18:31

mariadb-server-core-10.6_10.6.5+maria~bullseye_..>	6.2 MiB	2021-Nov-06 18:35

...

mariadb-server_10.6.5+maria~bullseye_all.deb	2.8 KiB	2021-Nov-06 18:31

mariadb-server_10.6.5+maria~buster_all.deb	2.8 KiB	2021-Nov-06 18:22

mariadb-server_10.6.5+maria~sid_all.deb	2.8 KiB	2021-Nov-06 18:36

As Salsa-CI is much slower and less flexible than MariaDB buildbot it been longer to test stuff. I have investigate local Salsa-CI Container setup but it''s also on back burner. Finally this is on stage where Patch on be tested on 10.8 and get it working on Salsa-CI then upgrade as most parts are on green and those that are not has to tackled with upstream Lintian or turned off.

Now project is getting in state where 10.7 is building correctly in Salsa-CI and 10.8 and 10.9 needs just minor fixes before they build correctly and after that we can remove Suffix and be fairly sure that everything does not break on Debian Salsa-CI side and also with official packages from MariaDB Foundation.

Now after merging Salsa-CI stuff and other fixing at last real work on this can be started otherwise than just making PR

First clean Salsa-CI build on 10.8 https://salsa.debian.org/illuusio/mariadb-server/-/pipelines/367622 now update to 10.9

Salsa-CI is now clear also for 10.9: https://salsa.debian.org/illuusio/mariadb-server/-/pipelines/368232

This should now be working as it was and should be reviewed deeper and after that implement what is found

Good work. While the two subtasks are there, they should be resolved rather quickly with PRs existing and aren't technically blockers.

Docker Library Container update