Web lists-archives.com

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