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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6H82YgdU83HKsm=S=m=njnkqy3_egp3eu_fpbbjdaz...@mail.gmail.com
