Re: Survey: git packaging practices / repository format
On Tue, 28 May 2019 at 16:51:10 +0100, Ian Jackson wrote:
> Unmodified debian/patches gbp, gbp pq
> upstream files, (only) quilt / dquilt
> plus debian/* Manual patch editing
> incl. d/patches
Do you intend "manual patch editing" to include, for example, fetching
patches from upstream's gitweb or mailing list or equivalent, or
generating patches from a parallel VCS checkout of the upstream code?
> Only debian/*, d/patches, only; gbp ?
> with d/patches Baseline upstream: quilt/dquilt ?
> changelog version =>
> .orig tarball(s)
gbp pq cannot be used for this: it relies on the first setup that I
quoted above. To manage patches in this kind of repository, you need to
either use quilt or similar, or some out-of-band mechanism.
When I've done this in the past, I usually fetched patches from
upstream's VCS repository via out-of-band mechanisms and dropped them
into debian/patches. Rebasing interdependent patches to apply cleanly
in this kind of repository is hard to do, and I would recommend doing
something else if your patch series is non-trivial.
These days I use gbp pq instead, and my only packaging-only repositories
are for non-textual game data that is too large for convenient use of
git and rarely meaningful to patch: if I wanted to add or change files
in those repositories, I'd put them in debian/ and arrange for them to
overwrite the ones that upstream provided, rather than trying to do
incremental patches.
(If I wanted a better workflow for mostly-non-text-based packages,
I'd be looking into storing the binary blobs with git-annex or git-lfs
rather than plain git.)
Some other classes of package I've encountered (I don't maintain these
and wouldn't recommend their layouts, but they exist):
Relying on debuild -i (e.g. gcc-8)
==================================
Tree contains: usually unmodified upstream files, but could be any of
your examples
Changes to upstream source are: any of your examples, except that changes
to /.gitignore don't appear in d/patches even if other delta does
Patches managed by: any of your examples
Special build tool: use debuild -i (or
debuild --extend-diff-ignore='(^|/).gitignore$')
Debian Linux kernel
===================
Tree contains: an incomplete debian/ directory, notably without d/control,
and no upstream source
Changes to upstream source are: d/patches only
Baseline upstream: changelog version => .orig tarball
Patches managed by: ???
Special build tool: there is a pre-build step to generate d/control
Ubuntu Linux kernel
===================
Tree contains: upstream Linux source code plus an incomplete debian/
and a debian.master/ directory that I do not really understand
Changes to upstream source are: ???
Patches managed by: ???
Special build tool: there is a pre-build step to generate the missing
parts of debian/ from source that includes debian.master/
xorg-team (e.g. mesa)
=====================
Tree contains: upstream files from a git tag (not identical to the
upstream `make dist` tarball), sometimes with extra commits cherry-picked
Changes to upstream source are: applied directly or via d/patches,
sometimes a mixture within the same package
Baseline upstream: changelog version => .orig tarball; files that
exist in git but not in the upstream tarball are compensated for by
extend-diff-ignore in debian/source/local-options
Patches managed by: a mixture of git cherry-pick and quilt
Regards,
smcv
Reply to: