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:
http://wiki.debian.org/UpstreamGuide
> We're wanting to have Percona XtraBackup be part of Debian.
Excellent.
> 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:
http://www.debian.org/devel/wnpp/#l3
http://www.debian.org/Bugs/server-control#retitle
http://www.debian.org/Bugs/server-control#owner
> We are going to make "upload release to Debian" be part of our release
> process.... We want to be an active and involved upstream.
Great.
> 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
(percona-xtrabackup_2.1.3-610-1.dsc)
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:
http://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package
Also, I encourage you to sign your Debian packages and also your
upstream tarballs using OpenPGP keys. Here are some best practices for
OpenPGP:
https://we.riseup.net/riseuplabs+paow/openpgp-best-practices
> 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':
http://faif.us/cast/2013/may/07/0x3C/
> 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.
http://wiki.debian.org/Arm64Port
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: