Differences between revisions 33 and 34
Revision 33 as of 2014-02-03 16:25:25
Size: 10147
Editor: ?OttoKekalainen
Comment:
Revision 34 as of 2014-02-03 21:15:52
Size: 10224
Editor: ?OttoKekalainen
Comment:
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
 * build status: https://buildd.debian.org/status/package.php?p=mariadb-5.5

Status

Debian

Downstream

Ubuntu waiting for Debian to progress:

Building

Example commands for git-buildpackage with pbuilder:

  ## Create pbuilder environment (change DISt and ARCH do make as many you want)
  export DIST=wheezy && export ARCH=amd64
  sudo apt-get install debian-archive-keyring
  git-pbuilder create --mirror http://ftp.fi.debian.org/debian/ --debootstrapopts --keyring=/usr/share/keyrings/debian-archive-keyring.gpg
  # Manually create and delete directories is pbuilder fails to do so, e.g. on re-launching 'create': sudo rm -rf /var/cache/pbuilder/ba*
  # Faster disk usage
  git-pbuilder login --save-after-login
  root@host:/# apt-get install eatmydata
  root@host:/# exit

  ## Build packages for series defined in DIST and ARCH
  mkdir $DIST-$ARCH
  cd $DIST-$ARCH
  git clone git://github.com/ottok/pkg-mariadb.git
  # Clean up parent dir from all files except the .orig.tar.gz file
  # which is always the same from build to build
  ls . | grep -v orig | grep -v pkg-mariadb | xargs rm
  cd pkg-mariadb
  git pull
  export DEB_BUILD_OPTIONS=nocheck
  time git-buildpackage --git-pbuilder --git-dist=$DIST --git-arch=$ARCH
  cd ..
  lintian --info -I -E --pedantic --color=auto *.changes
  cd ..
  dpkg-scanpackages $DIST-$ARCH/ /dev/null | gzip -9c > $DIST-$ARCH/Packages.gz
  dpkg-scansources $DIST-$ARCH/ /dev/null | gzip -9c > $DIST-$ARCH/Sources.gz
  cd $DIST-$ARCH
  # Finally upload to public testing server
  rsync -avz --delete-after *.gz *.build *.dsc *.changes *.deb labs:/home/otto/public_html/mariadb-repo/$DIST-$ARCH

  # Go Ping! when done
  paplay --volume=65536 /usr/share/sounds/freedesktop/stereo/complete.oga

  # Sign with Otto's key and upload
  debsign -k B7F7E4E1 *.changes
  dput mentors *.changes

Binaries for public testing

Latest test packages can be installed after adding the sources.list line corresponding to your distro:

  # Debian stable
  deb http://labs.seravo.fi/~otto/mariadb-repo/ wheezy-amd64/
  deb http://labs.seravo.fi/~otto/mariadb-repo/ wheezy-i386/

  # Debian unstable
  deb http://labs.seravo.fi/~otto/mariadb-repo/ sid-amd64/
  deb http://labs.seravo.fi/~otto/mariadb-repo/ sid-i386/

  # Ubuntu unstable
  deb http://labs.seravo.fi/~otto/mariadb-repo/ saucy-amd64/
  deb http://labs.seravo.fi/~otto/mariadb-repo/ saucy-i386/

The directory http://labs.seravo.fi/~otto/mariadb-repo/ is browseable and there you can also find build logs and source packages.

Same packages mirrored at Launchpad to provide standard Ubuntu PPA:

Packaging background

How MariaDB works

  • Simply writing apt-get install mariadb-server will install MariaDB 5.5.x and replace any existing MySQL 5.5.x installation and inherit the databases and configuration files of it. Installing mysql-server will do the opposite. However running mysql-server will might raise issues if my.cnf contains something MariaDB-specific or if the database files have some MariaDB-specific table metadata). On those cases MySQL should fail gracefully by simply refusing to start until conditions are correct.

  • Most MariaDB packages have in the control files Provides+Breaks+Replaces for equivalent MySQL packages, so that it is impossible to install both at the same time. Many of the packages contain the same (and thus conflicting) file names and paths as in equivalent MySQL packages.

  • Upstream MariaDB 5.5.x advertises to be a binary-compatible replacement for MySQL 5.5.x (but not anymore in MySQL 5.6 vs. MariaDB 10.0). Anything that works with MySQL 5.5 will work with MariaDB 5.5. Migrating from MySQL 5.5. to MariaDB 5.5. will always work. The contrary might not always be true, as at least MariaDB 5.5 libraries (/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18.0.0) have more symbols (e.g. async support) than the MySQL version and some MariaDB enhanced database tables may be unreadable by MySQL 5.5.
  • Possible "interfaces" of MySQL 5.5 are the server and client binaries (can be used e.g. in shell scripts), the actual server interface (used remotely via port 3306 or locally via socket /var/run/mysqld/mysqld.sock) and the binary interfaces (/usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0 and some symbolic links to it, installable from package libmysqlclient18). MariaDB has all of these interfaces, plus the extra libmariadbclient18.x.

  • As upstream MariaDB 5.5 is quite a young fork of MySQL, all of the internal file names still have mysql in them, the database files are in the same location, the configuration file /etc/mysql/my.cnf is the same, the port 3306 is the same etc.

  • In Debian packages, libmysqlclient.so.* has been renamed to libmariadbclient.so.* to enable both versions to be installable side-by-side. Initial checking did not find that MySQL nor MariaDB would themselves use the shared libs, but have their own libs statically linked in. These shared libs are meant only for third party usage, and the libs themselves will use whatever server is installed (MySQL or MariaDB). While libmysqlclient18 and libmariadbclient18 are co-installable, the -dev versions have files with same filenames and they conflict, thus making -dev versions NOT co-installable.

  • Mariadb-common is an empty metapackage that depends on mysql-common. MariaDB 5.5 can always use a my.cnf that originates from MySQL 5.5, but it might not work the other way around if the user has added some MariaDB-specific parameters in the my.cnf. The default my.cnf should always be compatible with all MySQL and MariaDB versions (5.5, 5.6, 10.0 and foreseeable future). Any options which are unique to one or the other must never appear in a shipped my.cnf.

  • To mitigate migration confusion, installing MariaDB will show an dialog notifying about the potential one-wayness of the migration.
  • As MariaDB stores data in /var/lib/mysql, there might be issues if somebody wants to run MySQL after using MariaDB for some time. We could ask upstream to copy /var/lib/mysql into /var/lib/mariadb to be on the safe side. In Debian installing MySQL after MariaDB could also be seen as a downgrade, and trigger the mariadb-server-5.5.preinst:77 downgrade warning. The current solution is simply to issue a warning at MariaDB installation time that the migration for some parts in a one-way migration.

Regarding circular dependencies:

In the future it might be possible to run something like

   licensecheck --copyright -r . -c . | /usr/lib/cdbs/licensecheck2dep5 > /tmp/copyright

..but at the moment it does not work, so the license file is a hybrid with automation plus manual clean up.

Script license-reconcile can be used to lint the copyright file, but it cannot generate a correct file.

Related issue filed upstream: https://mariadb.atlassian.net/browse/MDEV-5483

TODO

Urgent items

  1. Rename git repo from pkg-mariadb to pkg-mariadb-5.5

  2. Replace current git branch upstream with git-buildpackage pristine-tar format. While at it, use new upstream file hash checker: As of devscripts 2.13.3, uscan now supports verifying cryptographic signatures on upstream source via the pgpsigurlmangle option in debian/watch. See uscan(1) for details and examples.

  3. Wait for .35 to be released by upstream. Then update packages directly to .35.

  4. MariaDB 5.5.34 upstream has introduced /usr/lib/mysql/plugin/dialog.so in libmariadbclient18, which conflicts with libmysqlclient18. Create a rename hack and ask for upstream to make a proper fix.
  5. SONAME is defined inside the shared library and to change if the build source itself must be updated. TODO: find the line where libmysqlclient18 is defined and make git-buildpackage patch to change it (or let upstream do it better, filed issue https://mariadb.atlassian.net/browse/MDEV-5482)

       $ objdump -x /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 | grep SONAME
         SONAME               libmysqlclient.so.18
  6. Test .35 and then upload .35 to Debian, also upload to Ubuntu and make sure all is OK for 14.04 release.

Long-term items

  1. Change target from sid to unstable for .changes files to be perfect.

  2. Review debian/patches, do we really need them? At least remove the temporary mysqld_safe-extrafix which was added only to satisfy dpkg-source nag.

  3. Figure out optimal way to add Ubuntu patches upon the Debian base and after that file issue upstream to get rid of debian/dists/(Debian|Ubuntu) folder.
  4. Figure out and document the optimal workflow to from importing upstream changes (using git-dch with correct parameters etc), committing, testing and all the way to uploading into Debian.
  5. Discuss with upstream to bump up the Debian policy version, rename *.files into *.install etc.
  6. Talk with upstream about autobake.sh and possible removal or simplification to run same build process as Debian does.
  7. Ask upstream to have one autobake run for our git also, so that we can benefit from the continuous integration system there https://mariadb.com/kb/en/package-testing-with-buildbot-and-kvm/

  8. In general, minimize delta with upstream to make maintenance and updates easier.
  9. Package MariaDB 10.0 for Debian
  10. Package MariaDB Galera Cluster for Debian