[pkg-apparmor] Bug#888244: apparmor: Convert quilt patch series to per-topic subdirectories managed by gbp-pq

[intrigeri at debian.org]

Source: apparmor
Version: 2.12-1
Severity: minor
X-Debbugs-Cc: Simon McVittie <smcv at debian.org>

As mentioned when we discussed moving the packaging to Git, I want to
use gbp-pq. This is not feasible yet because lots of metadata about
our patch series is encoded with comments in d/p/series and gbp-pq
drops all this info.

Thankfully there's a way to store this metadata in a more structured
way: we can store patches in sub-directories of d/patches/ and use
gbp-pq's "topic" concept. For example, see how it's done for
src:systemd:
https://anonscm.debian.org/git/pkg-systemd/systemd.git/tree/debian/README.source?h=debian/236-3#n28

So I propose we reorganize the patch series this way:

 - Upstream cherry-picks and patches already submitted upstream go
   into the "empty" topic (i.e. directly into debian/patches/)

   Currently we have two different sections for those in d/p/series:
   "Patches backported from upstream commits" and "Patches backported
   from upstream fix submissions", presumably to encode the "has the
   patch been applied upstream yet?" information. But very often this
   info is outdated so I propose to stop pretending we can maintain
   it consistently.

 - Patches applied on Debian and presumably all derivatives, that are
   not applicable upstream, go into "Gbp-Pq: Topic debian" (i.e.
   debian/patches/debian/)

   These are those corresponding to lines that are currently not
   commented out on the debian/master branch in the "Ubuntu-specific
   patches" section of d/p/series. So far our patch series has been
   organized under the assumption that the Debian packaging is
   a derivative of the Ubuntu one; I don't think this reflects reality
   anymore so let's instead organize it under the assumption that the
   Ubuntu packaging is a derivative of the Debian one.

   For example, we would have
   debian/patches/debian/libapparmor-layout-deb.patch

 - Patches applied on $derivative go into "Gbp-Pq: Topic $derivative"
   (i.e. debian/patches/$derivative/).

   For example, we would have
   debian/patches/Ubuntu/profiles-grant-access-to-systemd-resolved.patch
   (it requires fine-grained AppArmor mediation of D-Bus traffic,
   which one cannot expect to have outside of Ubuntu).

   We could have a sanity check in debian/rules that ensures no such
   patch is enabled when `dpkg-vendor --derives-from Ubuntu' returns
   non-zero.

 - I'm not sure what to do about patches that Debian wants but Ubuntu
   doesn't. Thankfully this is a very rare case, of which we currently
   have only one instance (pin-feature-set.patch). I propose we put
   them into a "debian-only" topic; and we could have a check in
   debian/rules that ensures no such patch is enabled whenever
   `dpkg-vendor --is Debian' returns non-zero.

 - The only patch we have that's not covered explicitly by the above
   proposal is non-linux.patch: if we don't drop it (yet?) it would
   logically fit in "Gbp-Pq: Topic debian" (there's a good reason not
   to apply it upstream but Debian currently wants it and it's
   harmless on derivatives that have no non-Linux port).

Then gbp-pq will construct a d/p/series file that's basically the same
as we have currently, slightly reordered, and without comments; any
information stored there in comments currently would be encoded either
by the topic the patch is stored in, and when that's not enough by
DEP-3 headers (e.g. the explanation of why a given patch is applicable
on Ubuntu but not on Debian, or of why another patch is applicable on
Debian but not upstream).

I'll prepare a PoC branch but you folks don't have to wait for it
before you comment. I'll include documentation about patch handling
based on src:systemd's d/README.source.

Thoughts?

In particular I'd welcome input from Simon who, I believe, has built
extensive experience with using gbp-pq's "topic" concept in
similar situation.

Cheers,
-- 
intrigeri