[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ITP: Percona XtraBackup - hot backup utility for MySQL

On Tue, Jul 2, 2013 at 2:41 PM, Stewart Smith wrote:

> 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.

Since you are part of upstream, please review our upstream guide and
the links in the external advice section:


> We're wanting to have Percona XtraBackup be part of Debian.


> There is an open bug for Percona XtraBackup packaging:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620824

Since you intend to package it, you should retitle this bug to intent
to package and set yourself as the owner of it:


> We are going to make "upload release to Debian" be part of our release
> process.... We want to be an active and involved upstream.


> 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/

I'm unable to unpack the source package:

$ dpkg-source -x percona-xtrabackup_2.1.3-610-1.dsc
dpkg-source: warning: extracting unsigned source package
dpkg-source: error: File ./percona-xtrabackup_2.1.3-610.orig.tar.gz
has size 39459 instead of expected 141074103

You may want to run some commands from the source tree after a build:


Also, I encourage you to sign your Debian packages and also your
upstream tarballs using OpenPGP keys. Here are some best practices for


> 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)

An alternative to including the MySQL InnoDB code might be to
build-depend on mysql-source-5.5, unpack and patch it during the build
process and add Built-Using: mysql-5.5 (= $version) to the resulting
binary package.

> 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?

Seems reasonable to include it if you really want to. There seem to be
more folks using percona-xtrabackup than xtrabackup though:

$ GET http://popcon.debian.org/unknown/by_inst | grep -i xtrab
1590  percona-xtrabackup               150    36    82    32     0
(Not in sid)
2170  xtrabackup                        98     5    29     0    64
(Not in sid)
23575 percona-xtrabackup-test            3     0     2     1     0
(Not in sid)
31597 percona-xtrabackup-dbg             2     0     2     0     0
(Not in sid)
74903 szn-mysql-xtrabackup               1     0     1     0     0
(Not in sid)

> 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.

I'd suggest mailing debian-legal about this question but based on the
trademark policy it appears that Debian would have to rename percona
if we wanted to add a security patch in stable?

You may want to listen to this FOSDEM talk entitled 'How to Share a Trademark':


> 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?

There is no requirement to work on all arches but regressions in
architecture support are release-critical. You need to have a good
test suite so that binary packages are not produced on architectures
where the software doesn't work. I expect you will want to make it
work on ARM since arm64 is coming soon and may become a popular
architecture for servers.




Reply to: