Hi! I'm Stewart and I work for Percona. One of the things I'm currently working on is ensuring all our free and open source software projects are packaged for all the major linux distributions - including my beloved Debian. We're wanting to have Percona XtraBackup be part of Debian. Percona XtraBackup is an online backup tool for MySQL, MariaDB, Percona Server and Percona XtraDB Cluster. In the near future, we will also wanting our packages for Percona Server and Percona XtraDB Cluster to be part of Debian. There is an open bug for Percona XtraBackup packaging: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620824 We are going to make "upload release to Debian" be part of our release process. We tend to make a new minor bugfix release (i.e. 2.1.x) every 2-3 months and a new major release every 12 (2.0 in April 2012, 2.1 in May 2013). We want to be an active and involved upstream. There have been a couple of issues with our source tarballs and build procedure that I've had to fix up before proposing that Percona XtraBackup be included. I've made changes on top of our 2.1.3 release that mean we now generate source tarballs that do not require an active internet connection to build. I've put up source tarball and packaging for unstable up at: http://www.percona.com/downloads/TESTING/XtraBackup/xtrabackup-2.1.3/release-2.1.3/610/source/ All future releases will produce tarballs like this, so they'll be in a more normal area of our downloads site - I'll also get one up in an official place for the current 2.1.3 release. I (and we, the rest of Percona) would really appreciate any review/comments/suggestions on this packaging - we're really keen to have Percona XtraBackup be in the Debian archives. Why is the tarball so big and why did it require an internet connection? Well, XtraBackup uses *part* of the MySQL code (actually, mostly parts of InnoDB) to help it read InnoDB pages from disk and back them up safely. It also uses part of the code to replay REDO logs to prepare a backup before it can be restored. Due to various not-that-interesting reasons (all of which we do consider bugs) we currently produce different binaries for different MySQL versions (hence linking in code From different MySQL versions). It's important to note that we patch the InnoDB code inside MySQL to make it usable by xtrabackup and that we cannot just use the MySQL code already shipped in Debian for this without creating a nightmare for the Debian MySQL packaging team, the security team and ourselves (it's generally non-trivial to port this patch to new versions). There should never be any security implications of linking against this (not always up to date) MySQL code as we only use it to read (and write) files to local disk. Questions: 1) We have a transitional package called 'xtrabackup' that was (prior to 2.0) the package name was in our own APT repositories. Does it make sense to keep this in the Debian packaging? 2) We have trademarks. We've tried to come up with a trademark policy that makes everybody happy (well, as happy as you can be when you're dealing with trademark law). It's at: http://www.percona.com/doc/percona-xtrabackup/2.1/trademark-policy.html We believe this should satisfy any requirements of Linux distributions, but if there's any concerns, don't hesitate to ask. 3) Supported architectures. We see x86-64, x86 and very, very rarely, SPARC. I'd say that both people running XtraBackup on a non-x86 architecture are happy, but I'm pretty sure there's not even that many. While XtraBackup may compile (or even run) on other architectures, it currently makes approximately zero business sense for us to spend any time on it - although we're happy to take patches. Given this, how much "works and passes tests on all archs" is required to have packages accepted? 4) We plan on continuing to provide our own repositories as well and are wanting to not diverge in packaging from our repos and what's in Debian. Any tips/tricks are very welcome - we have "build debian packages" as part of or continuous integration efforts and plan to soon have "run the whole test suite on those packages" as part of it. Thanks in advance for the feedback! -- Stewart Smith
Attachment:
pgp7eqhIWa4LF.pgp
Description: PGP signature