[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 7:35 PM, Stewart Smith wrote:

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

Looks like your tarball is named incorrectly (tar.gz instead of
orig.tar.gz) and your website returns a HTTP 302 code (redirect) and
some HTML for the orig.tar.gz URL rather than a 404.

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


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

It is a reasonable approach for upstream tarballs. Uploads to Debian
need to be signed by one of the keys in the developer keyring or a
subkey of one of those keys.

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

I see, maybe you have chosen the way of least pain.

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

Maybe ask your userbase if they need it?

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

The danger is if that approach to interpretation if the policy were to change.

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

Please do enable the test suite for Debian builds and run them with
the binaries built during the build process.



Reply to: