Simon McVittie writes ("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?
Obviously that needs to be included here. I'm struggling with a brief
way to express it. Maybe that is a fool's errand, and it would help
people recognise their own practices if it were less brief.
> > 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.
git-buildpackage can build such things, I recently learned.
I have snipped the parts of your message that might be read as an
opinion about what is best, for the reasons explained in my last mail
:-).
> 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$')
I'm not sure I understand this one.
Is this actually a packaging format or patch management workflow, or
is it something else ?
I am leaving aside the .gitignore thing for this survey. It is a
wrinkle. Most of the tools I mention in the survey have an opinion
about the .gitignore thing but it is just confusing detail in this
context.
> 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
Thanks, I will add this to my survey. I assume "patches are managed
by" is the same as any other only-debian/* tree. The wrinkle is the
need for a special build tool.
> 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/
Same here.
> 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
Likewise.
Thanks,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
