Re: Survey results: git packaging practices / repository format
On Fri, 05 Jul 2019 at 01:07:59 +1200, Daniel Reurich wrote:
> Our packaging approach is more or less "unapplied" for 3.0(quilt)
> packages, and (I think) pretty much universally using quilt and gbp -
> only for changelog and buildpackage (because it does a nice pbuilder
> based build process with all the checks for ensuring no stray patches to
> the upstream source sneak in).
Note that quilt and gbp-pq interoperate (they are both "unapplied" as far
as this survey is concerned) so if some of your developers prefer gbp-pq,
some prefer quilt, and some prefer dropping "git format-patch" output
into debian/patches without any special tools, that isn't particularly
problematic.
This matches what we do in the Debian derivatives I work on for my job,
although we tend to use gbp-pq more than quilt.
> We've universally stamped out using pristine tar ;-) and always use use
> either upstream-branch or preferably upstream-tag.
How do you get a .orig tarball that matches what your upstream released
(if not repacking)? For packages you already have in your archive, how
do you ensure that you get a .orig tarball that exactly matches the one
already there?
There isn't enough information in the packaging and upstream branches
of a typical git workflow to reconstitute a precisely matching .orig
tarball: you have to either obtain .orig tarballs out-of-band, or use
pristine-tar to encode the parts of the tarball that can't be reproduced
from the git tree.
(This is less of a problem if you never package upstream versions of
non-native packages that aren't already in Debian, because in that case
you can obtain the .orig tarball out-of-band from the Debian archive, but
for more general downstreams, having interesting packages at a strictly
newer version than Debian, or packages that aren't in Debian at all, is
sometimes necessary. I'd be somewhat surprised if Devuan never pulls in
a newer upstream version, or an upstream package that isn't in Debian at
all, for the packages that are only interesting in the non-systemd case,
like elogind and the various non-systemd init systems.)
> There was one outstanding issue in the "gitsrc" discussion that I had,
> and that was clear handling of patches to the upstream source. The best
> answer I can come up with that is to use a sub vendor namespace
> "patches" and a branch per patch
> ie "debian/patches/01-<brief-descriptor>"
Can this approach cope with patches that textually depend on each other,
like two commits that alter the same region of the same file, one after
the other? (I can't see how it would, but perhaps I'm missing something.)
As far as I can tell, gitsrc was intended to be used with some
patches-applied representation of a source package ("merging",
"git-debrebase", "git-dpm", "git-debcherry" or "rebasing" in the
table), similar to dgit's native "archive" representation, and unlike
the patches-unapplied representation ("maintainer view" in dgit terms)
that is used in your workflow (and mine).
smcv
Reply to: