On 15/08/14 15:16, Raphael Hertzog wrote: > Some initial questions and possible answers:
I've been hesitating on whether to ask this because it gets into questions of workflow and repo structure that are very much a matter of taste and don't have a single widely-declared-to-be-good answer, but I think one of the important questions is: what is actually on the vendor (e.g. Debian) branch? The big question is "are vendor patches pre-applied or not?" but a follow-up question, for 3.0 (quilt) packages, is "does .pc reflect that?" I use gbp-pq for my own packages, so I would appreciate it if people who actively use the other repo structures/helper tools could correct my mistakes and discuss their advantages and disadvantages. gbp-pq (from git-buildpackage), with imported tarballs in git ------------------------------------------------------------- gbp-pq encourages the answer to be "pristine contents of tarball plus a debian/ directory containing a quilt patch series, those patches are *not* applied to the upstream sources as they appear in the repo, .pc does not exist". This is the policy in all the teams in which I'm active (possibly excluding pkg-games which might not have an overall policy) and the one I personally prefer, at least at the moment. It has the advantage that you don't have to rebase a published branch (which is Bad™) in order to rebase the vendor patches onto new upstream versions (which is something you'll be doing all the time in most packages). It has the disadvantage that you can't just cherry-pick an upstream commit, you have to do non-git-ish things like dropping a git-format-patch into debian/patches or using gbp-pq. systemd's current README.source <http://sources.debian.net/src/systemd/208-7/debian/README.source/> is a good set of instructions for doing common maintainer/NMUer things in a gbp-pq tree. You can also build from such a tree with a plain `dpkg-buildpackage`. I conjecture that maintainers who are used to things that are not git (particularly svn, as used by pkg-perl, pkg-gnome, pkg-python-* etc.) will also feel at home with this structure: it is entirely possible to not use gbp-pq, and instead apply/unapply patches with quilt. git-import-orig knows how to merge upstream VCS tags into an upstream branch that is otherwise based on imported tarballs, so it is possible to have the upstream/* commits reflect what was in imported tarballs but still have your upstream's git commits as an ancestor. gbp-pq (from git-buildpackage), with upstream git as base --------------------------------------------------------- As long as you don't need to patch any files that do not exist in upstream git but only in the tarball (e.g. use dh-autoreconf instead of patching Makefile.in), and you don't have to drop any upstream files (e.g. for DFSG reasons), it is possible to use upstream git as your basis for branching, instead of importing tarballs. That's how systemd is packaged at the moment. git-buildpackage --git-export, with only debian/ in git ------------------------------------------------------- It is possible to use git-buildpackage with --git-export (either explicitly, or configured in debian/gbp.conf) for packages that only keep debian/ in git. In this situation, the only possibility is to have patches *not* pre-applied, because there is nothing there to patch. This matches how teams like pkg-gnome have traditionally used svn. I would strongly recommend having upstream source in git, not just debian/, with one exception: packages like openarena-data, which mostly contain giant binary files that cannot meaningfully be patched. git-dpm ------- git-dpm encourages the contents of the vendor branch to be "exactly the source that will be built, vendor patches *are* applied" and uses a relatively elaborate merging structure to avoid rebasing (<http://git-dpm.alioth.debian.org/>). I don't know whether .pc is typically present in the tree for 3.0 (quilt) packages or not, or whether users of git-dpm avoid 3.0 (quilt) format altogether. gitpkg ------ As far as I can tell, gitpkg encourages the answer to be "exactly the source that will be built, vendor patches *are* applied, but .pc is not present in git". However, I could be wrong. When I tried to apply downstream patches to a version of systemd that used gitpkg, I got confused enough to just give up on using the maintainers' git tree and re-import it with git-import-dsc instead. (systemd has since switched to the gbp-pq layout, which I found much easier to deal with.) dgit ---- dgit encourages the answer to be "exactly the source that will be built, vendor patches *are* applied, if the package uses 3.0 (quilt) then .pc also exists and reflects the state of the tree". I'm not sure what techniques dgit users use to deal with non-native packages that have vendor patches without rebasing a published branch - git-dpm seems like it might be a good fit? There seems to be a strong correlation between happy dgit users, and those who either only do native packages (hello joeyh) or consider 3.0 (quilt) to be an abomination and are sticking with source format 1.0 (hello iwj); so the .pc thing might not matter to these users in practice, but is significant do those who do want 3.0 (quilt). If being VCS-agnostic is valued, it might be an interesting exercise to design a source package format that is meant to work well with sources in a dgit-style DVCS (e.g. avoiding clutter like .pc/ when unpacked), but does not specifically rely on git concepts and formats. Alternatively, perhaps it's time for a 4.0 (git) source format to become a reality, if someone cleverer than me can devise a way to avoid it containing the full history (which would not be feasible for ftp-masters to review, and is reasonably likely to contain accidental sourceless or non-free files). Regards, S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ee4c14.2040...@debian.org
