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

[Seth Arnold]

On Fri, Sep 03, 2021 at 10:10:44AM +0200, intrigeri wrote:
> intrigeri (2021-02-06):
> > intrigeri at debian.org (2020-10-25):

Wow, you've got a great memory. :D

At least libapparmor-perl shouldn't be changed to arch: all:

± apt-file show libapparmor-perl
libapparmor-perl: /usr/lib/x86_64-linux-gnu/perl5/5.30/LibAppArmor.pm
libapparmor-perl: /usr/lib/x86_64-linux-gnu/perl5/5.30/auto/LibAppArmor/LibAppArmor.so
...

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.

(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.)

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.

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

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-apparmor-team/attachments/20210903/1b75b6b2/attachment.sig>