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

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

Paul Wise <pabs@debian.org> writes:
> 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

Thanks for the pointer. It appears that we're pretty good on most things
mentioned there and some things we've got plans to address.

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


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

I'll investigate this first thing in the morning (it's getting late),
although it looks as though the tar.gz didn't fully download (yes, it's
really 135MB)

> You may want to run some commands from the source tree after a build:
> http://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package

I think there's some good ideas here that we can add to our CI
infrastructure. I don't think there's anything that would be considered
a blocker though.

> 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

Yep, we typically do this. We use a key for the company rather than our
individual ones for our current repositories. Is this an acceptable
approach for packages going into Debian? Or should we just have the few
individuals sign it if they're involved?

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

We'd need to depend on very specific 5.1, 5.5 and 5.6 versions of both
MySQL and Percona Server (which isn't yet packaged) and we'd also have
to patch it.

Our short/medium term plan is to do away with having multiple server
source trees and binaries. We instead plan to just make a modified MySQL
branch where we just include the needed (modified) source. In an ideal
world the needed code would be buildable as a library and we'd get the
needed patches upstream. It is not an ideal world however :(

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

I'm not really attached either way... It appears that it may not be
worth having it. I'll defer to the experts on this one.

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

I'll bring it up there. We would see that as simply a patch that's
needed for that version to be included in that Os and thus not an issue.

> You may want to listen to this FOSDEM talk entitled 'How to Share a Trademark':
> http://faif.us/cast/2013/may/07/0x3C/

I'll have a look. We tried to think of linux distros and Debian when we
were forming the trademark policy. We'll see what Debian-legal says :)

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

It's certainly something we may be interested at looking at... I guess
we'll see what the buildds say :)

We do have a test suite. It does (of course) depend on having server
binaries around to run backup and restore with. Our CI infrastructure
currently uses just binary tarballs of various server versions, but this
probably isn't ideal for Debain so we'll have to come up with another
solution. One thing to consider is that (like MySQL) running the test
suite takes a non-trivial amount of time.

Stewart Smith

Attachment: pgpEuDSs0a949.pgp
Description: PGP signature

Reply to: