[pkg-apparmor] Bug#972881: Bug#972881: Consider making apparmor-utils, python3-apparmor, and libapparmor-perl arch:all

[intrigeri]

Hi,

Seth Arnold (2021-09-03):
> At least libapparmor-perl shouldn't be changed to arch: all:

Good catch, thanks!

> apparmor-utils and python3-apparmor feel like they're reasonable to
> convert to arch: all, though. If we wind up wanting to use compiled
> tooling in either of them in the future, we can just deal with the new
> constraint and create new packages.

Great.

> (It might be worth dropping libapparmor-perl entirely. the apparmor-notify
> package was the only thing to depend upon it, and that's been rewritten in
> python.
>
> There's of course the chance someone's built their own tooling using the
> perl bindings. Maybe we ought to go through a wider call-for-opinions
> or a formal deprecation process.)

I'll follow-up about this on the bug I have created for exactly this
a few days ago: #993565.

> Are there any lints or sanity checks available to see if the remaining two
> packages are good candidates for changing? I didn't spot any trouble
> myself but would hate to get it wrong.

I've compared the current arch:any binary packages, built on several
architectures, to see if there were any relevant differences. It turns
out that the only difference in the contents of these packages is the
value of the "Architecture" control field.

This makes me confident they're good candidates for becoming arch:all :)

FTR, I used diffoscope:

for arch in arm64 armel armhf i386 mips64el mipsel ppc64el s390x ; do
   diffoscope \
      python3-apparmor_3.0.3-2_amd64.deb \
      "python3-apparmor_3.0.3-2_${arch}.deb"
   diffoscope \
      apparmor-utils_3.0.3-2_amd64.deb \
      "apparmor-utils_3.0.3-2_${arch}.deb"
done

> Do we need to worry about eg :i386 and :amd64 package dependencies on a
> system suddenly changing to an :all package dependency?

I don't think so because there's no multi-arch stuff involved here.
More specifically:

1. I've checked reverse-dependencies currently in Debian:

   - tor and ejabberd have "Suggests: apparmor-utils"
   - apparmor-notify, apparmor-easyprof, and apparmor-utils have
     "Depends: python3-apparmor"

2. None of these 2 packages have any Multi-Arch control field, so
   there should be no system that has them installed 2+ times for
   several architectures.

⇒ I believe the transition on upgrade should be seamless,
but I'll of course test it before uploading.

Cheers!