Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-6284

Merge downstream Debian/Ubuntu packaging into upstream MariaDB

Details

    • 10.2.2-2

    Description

      == Motivation ==

      Merge downstream .deb-packaging into upstream MariaDB to unify, streamline and ease future release packaging. This will also fix some packaging errors in current MariaDB.org deb-packages.

      == Patch description ==

      List of notable changes:

      • Completely new Debian packaging standard (3.0 quilt) including rules file, patch conventions and .files -> .install file listing conventions
      • The will no longer be a debian/dist subfolder and the packaging of Debian an Ubuntu will be unified (= Debian will ship with AppArmor files included)
      • Support for Debian releases before Wheezy (7) and Ubuntu releases before Precise (12.04) will be dropped

      The upstream MariaDB contents of debian/* will not be fully identical to the downstream Debian/Ubuntu one.

      List of intended differences between Debian master and MariaDB master regarding debian/ contents:

      • control file: maintainer, uploaders, VCS and browser links
      • omitted packages (not allowed in Debian): libmariadbclient18, libmysqlclient18, libmariadbclient-dev, mysql-common
      • omitted plugins (problematic in Debian): Handler socket, TokuDB, Mroonga, Cassandra
      • keep autobake.sh in mariadb.org repo

      To close this bug please:

      1) Merge selected parts of debian/* from https://anonscm.debian.org/gitweb/?p=pkg-mysql/mariadb-10.0.git to https://github.com/MariaDB/server via pull requests arriving from branch ok-debpkg at https://github.com/ottok/mariadb

      2) Backport form MariaDB development head to 10.1, 10.0 and maybe even 5.5 commits that fix individual issues.

      == Quality assurance ==

      The new debian/* contents represents the state of the art of Debian packaging. The mariadb-5.5 and mariadb-10.0 has passed all Debian quality assurance and landed in the official Debian repositories. More details at https://wiki.debian.org/Teams/MySQL/MariaDB

      These same packages have also gone downstream to Ubuntu, has passed Ubuntu QA and are included since the Ubuntu 14.04 release.

      Buildbot test for ok-debpkg branch: https://buildbot.askmonty.org/buildbot/grid?branch=ok-debpkg&category=main

      == Roll-out planning ==

      This merge should be safe to release with 10.1. All new installs and upgrades using the MariaDB.org repo or mixing it with official Debian or Ubuntu repository contents is expected to work.

      Below are the different scenarios how releasing the new packging at MariaDB.org will affect current installs/upgrades:

      A) If users currently have a MariaDB.org repo enabled, those packages will have a + in their version number. Debian package manager will always consider e.g. 10.1.6+maria as more recent than 10.1.6 from the native repositories. Therefore people having MariaDB.org repositories will always get primarly the packages from MariaDB.org repositories. It is very unlikely that a Debian repository would ever have a more recent release than in MariaDB.org (e.g. 10.1.7 would override 10.1.6+maria, but that is not likely to take place as MariaDB.org always releases first).

      B) The new packaging is designed and tested that it allows seamless upgrades from old deb packaging generation to new generation. Whether the new packaging is from MariaDB.org or distro repositories does not matter.

      C) Backwards works only partially, but is a rare case (e.g. current Ubuntu users trying to upgrade from new style debs 10.0 to MariaDB.org repo old style debs 10.0 will see issues, e.g. MDEV-5977). As soon as this merge is done and MariaDB.org publishes packages using the new packaging this corner case is fixed.

      D) If users remove the MariaDB.org from their install, they will automatically have their 10.1.6+maria updated to Debian/Ubuntu native 5.5.39 once it is released in Debian.

      E) Like previously, upgrading from MySQL 5.5 to MariaDB 5.5 works seamlessly and backwards also. Updating from MariaDB 5.5 to 10.0 works seamlessly but backwards will have issues (downgrade flag, InnoDB log size mismatch etc) the package manager will not solve automatically. If users dump and import data manually, and in between completely purge and install the packages, then users can always migrate to whatever version.

      Attachments

        1. ottok.diff
          552 kB
        2. screenshot-1.png
          screenshot-1.png
          60 kB
        3. screenshot-2.png
          screenshot-2.png
          111 kB

        Issue Links

          Activity

            Side notice: seems mtr depends on patch and libtool-bin, need to add that as a run-time dependency:

            nano +2175 mysql-test-run.pl
             
            sub executable_setup () {
             
              $exe_patch='patch' if `patch -v`;
             
              #
              # Check if libtool is available in this distribution/clone
              # we need it when valgrinding or debugging non installed binary
              # Otherwise valgrind will valgrind the libtool wrapper or bash
              # and gdb will not find the real executable to debug
              #
              if ( -x "../libtool")
              {
                $exe_libtool= "../libtool";
                if ($opt_valgrind or $glob_debugger or $opt_strace)
                {
                  mtr_report("Using \"$exe_libtool\" when running valgrind, strace or debugger");
                }
              }
            
            

            Also, for all tests to run, they should be run as user 'mysql' with access to pam_auth_tool, and again with another user that is not in user.mysql by default. Also some tests only run when mtr is invoked with --big-test, there is IPv6 available, there is a Cassandra back-end running etc. I wonder how big tests should be run to validate that there are no testable regressions in this MDEV once all patches are done (it is going to be huge).

            otto Otto Kekäläinen added a comment - Side notice: seems mtr depends on patch and libtool-bin, need to add that as a run-time dependency: nano +2175 mysql-test-run.pl   sub executable_setup () {   $exe_patch='patch' if `patch -v`;   # # Check if libtool is available in this distribution/clone # we need it when valgrinding or debugging non installed binary # Otherwise valgrind will valgrind the libtool wrapper or bash # and gdb will not find the real executable to debug # if ( -x "../libtool") { $exe_libtool= "../libtool"; if ($opt_valgrind or $glob_debugger or $opt_strace) { mtr_report("Using \"$exe_libtool\" when running valgrind, strace or debugger"); } } Also, for all tests to run, they should be run as user 'mysql' with access to pam_auth_tool, and again with another user that is not in user.mysql by default. Also some tests only run when mtr is invoked with --big-test, there is IPv6 available, there is a Cassandra back-end running etc. I wonder how big tests should be run to validate that there are no testable regressions in this MDEV once all patches are done (it is going to be huge).

            This MDEV can be closed when all of these are green:

            https://salsa.debian.org/mariadb-team/mariadb-server/pipelines/124140

            otto Otto Kekäläinen added a comment - This MDEV can be closed when all of these are green: https://salsa.debian.org/mariadb-team/mariadb-server/pipelines/124140

            patch can be "suggested" or "recommended", because tests won't fail if it's not present, they'll be automatically skipped

            serg Sergei Golubchik added a comment - patch can be "suggested" or "recommended", because tests won't fail if it's not present, they'll be automatically skipped
            otto Otto Kekäläinen added a comment - - edited

            > Side notice: seems mtr depends on patch and libtool-bin, need to add that as a run-time dependency:

            Tested libtool-bin, but it did not provide any extended traces, on the contrary the trace lost the filename paths:

            Tested by running mtr (without --force and without --parallel) and then issuing in another windows `killall -s 6 mariadbd` comparing baseline and situation after running `apt install libtool-bin`.

            `patch` is already a suggests, no need to research it.

            otto Otto Kekäläinen added a comment - - edited > Side notice: seems mtr depends on patch and libtool-bin, need to add that as a run-time dependency: Tested libtool-bin, but it did not provide any extended traces, on the contrary the trace lost the filename paths: Tested by running mtr (without --force and without --parallel) and then issuing in another windows `killall -s 6 mariadbd` comparing baseline and situation after running `apt install libtool-bin`. `patch` is already a suggests, no need to research it.

            All but https://jira.mariadb.org/browse/MDEV-5484 and merging of patches (https://jira.mariadb.org/browse/MDEV-14900) is done, but I deem this issue now closed enough.

            otto Otto Kekäläinen added a comment - All but https://jira.mariadb.org/browse/MDEV-5484 and merging of patches ( https://jira.mariadb.org/browse/MDEV-14900 ) is done, but I deem this issue now closed enough.

            People

              otto Otto Kekäläinen
              otto Otto Kekäläinen
              Votes:
              5 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.