Re: Reducing allowed Vcs for packaging?
On Mon, 27 Feb 2023 at 00:17:41 +0100, Diederik de Haas wrote:
> Russ Allbery <rra@debian.org> wrote:
> > dgit maintains a history of every package in Debian.
>
> AFAIK the Debian Xen Team does use dgit (not surprising given dgit's
> maintainer (and author?)) ... and that drives me insane.
> I'm very sure that is due to me not understanding the concepts/idea/etc, but I
> can't wrap my head around it and it feels *to me* like it constantly rewrites
> the (git) history and then does a `git push -f` ... every time.
In most practical maintainer workflows, the Debian patch series
fundamentally *does* get rebased every time there is a new upstream
release (if not more often), so the various packaging workflows (including
at least gbp-pq and git-debrebase, possibly also git-dpm) are ways to
reconcile that with wanting the history to be fast-forwarding.
dgit is at least partially workflow-agnostic, but as a central design
principle it had to choose exactly one representation to be the canonical
one, and the one its authors chose was "patches-applied", meaning that
any Debian-specific changes to the upstream source code of a package are
already pre-applied in the version you get from dgit.
Many (perhaps most?) Debian packages in git use the "patches-unapplied"
layout compatible with quilt or `gbp pq`, in which the Debian-specific
changes in the public VCS only exist in debian/patches and are not
pre-applied to the upstream source code (similar to what we used to do
in cvs and svn); if using `gbp pq` (as I do), the patches do temporarily
get imported into git as a patch-queue branch, which gets rebased, but
that patch-queue branch isn't intended to be pushed anywhere. Examples
of this include everything maintained by the Perl, Python, GNOME and
systemd teams, and many others.
For packages that use the common patches-unapplied workflow, the
representation in dgit and the representation used by the package's
maintainer are not the same (dgit refers to this as "split brain mode").
Packages that I maintain, like dbus and flatpak, might be useful examples
for this. The representation you get from Salsa is the way I prefer to
work with the package, and the representation you get from `dgit clone`
is the way the dgit maintainers would prefer it to be represented. dgit
reconciles these two views of the world automatically for me when I
upload, so I don't need to do anything differently. See dgit-maint-gbp(7)
for more details from the dgit side. Using that workflow is a way I can
be nice to dgit users without changing how I interact with debian/patches
and without requiring my co-maintainers to do anything differently,
so I do that.
I suspect that the Xen packaging is using a different workflow that is
less focused on the "patches-unapplied" tree than mine is, perhaps based
on git-dpm or git-debrebase.
smcv
Reply to: