Web lists-archives.com

Re: Survey: git packaging practices / repository format

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

> 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



Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx>   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.