Re: Preferred git branch structure when upstream moves from tarballs to git
On Tue, 07 May 2019 at 19:25:39 +0100, Ian Jackson wrote:
> What I am primarily advocating for in this thread is that maintainers
> should choose `dgit push-source' over `dput' (where this is possible).
> This is the only way for a maintainer to provide users with the git
> history in a sensible form (ie, a form which does not require the user
> to know what special git practices the maintainer has adopted).
I think you're implicitly asserting here that the tree that exists in
a dgit commit (upstream source as conveyed by the orig tarball, with
debian/ added, with patches applied if any) is the only sensible form
for the git history of a Debian source package, and I don't think that's
something that has consensus.
Alternative "shapes" that other people advocate include: debian/ only
(a straightforward translation of typical packaging-in-svn to git);
patches-unapplied trees (as seen in e.g. the Perl, Python, GNOME teams);
debian/ overlaid onto upstream's git repository (as opposed to
upstream's tarball code-drops), with any differences between the orig
tarball and upstream's git repository papered over by
debian/source/local-options (as seen in the Xorg team).
I realise that you think (some or all of) those other "shapes" are not
sensible, and I realise that dgit's design requires a single canonical
result of importing a Debian source package, and I agree that as a
general operating principle it's undesirable that different packages
have their contents represented in different ways; but I don't think
it's necessarily helpful to assert that the representation chosen for
dgit is the only one that can be considered sensible, and I think you're
in danger of causing people who disagree with you on this point to not
consider dgit, which seems like the opposite of what you want.
I think the reason people are conflating the contents of the tree with
the workflow that was used to arrive at that tree is that the workflow
is not completely decoupled from the tree. This is most obvious with
git-dpm, which leaves a mechanically-generated file in debian/ that it
cannot work without (and that is only practical to maintain by using
git-dpm), but it's also true for other representations: for instance
gbp-pq normally uses a patches-unapplied tree as the interchange format
(requiring dgit to compensate for this difference in assumptions),
whereas git-debrebase requires patches-applied if I understand correctly.
The major interoperating "families" are:
* patches-applied: git-debrebase or dgit-maint-merge (and git-dpm would
be in this category if it didn't require extra metadata in debian/).
* patches-unapplied: gbp pq, or patches managed out-of-band with quilt
or by dropping git format-patch output into d/patches, either with full
source in git or with only debian/ in git (built with
gbp buildpackage --overlay, or by unpacking the orig tarball into the
source directory and avoiding committing it to git).
(Native packages, and non-native packages with no patches, can be seen as
a special case of either family - if you don't have any patches then it
doesn't matter whether you have applied them or not.)
I don't think it's coincidence that many of the larger teams in Debian,
in particular Perl and Python, have ended up with patches-unapplied. It's
a straightforward continuation of how we used to maintain packages in
non-git VCSs like svn, it only requires learning to use a tool like
gbp pq or quilt if you have enough non-orthogonal patches that they
need to be rebased on each other to apply cleanly, and it's a fairly
close match for how most non-Debian source packaging formats work
(for instance Fedora SRPMs, Arch Linux PKGBUILDs and Gentoo ebuilds all
involve committing unified diffs to their respective VCSs alongside the
equivalent of debian/control).
smcv
Reply to: