[pkg-apparmor] Bug#965360: apparmor-profiles: Please meke seperate packages for each apparmor profile

[intrigeri]

Control: tag -1 + wontfix

Hi,

… and sorry for the delay.

Mikhail Morfikov (2020-10-24):
> There are three ways of installing apparmor profiles in debian:
> - an app's package contains some apparmor profile
> - some packages contain lots of apparmor profiles
> - there are a few packages which contain an app's apparmor profile itself, for 
>   instance fwknop-apparmor-profile
>
> So it's a mess.

I understand this can be very confusing (I hope that's what you mean,
expressed in terms of resulting impact, rather than in a judgmental
manner). It's not news to me and I'm not surprised.

In particular, the status of profiles shipped in the apparmor-profiles
package often confuses folks (understandably!). As a result, the
workload this package has required from me in the last years is
disproportionately big, compared to its actual usefulness.

I've tried to improve this in Bullseye by clarifying the package
description, and including a reportbug script that asks users to
report bugs upstream. If this is not enough to make users'
expectations match our intent, or not enough to lower that workload,
then I plan to stop maintaining the apparmor-profiles binary package
in Debian myself.

> It would be nice to have profiles in individual packages, so users
> could decide what they want to install.

Thanks for clarifying what use case is currently poorly supported.

It seems to me that we want to optimize the user experience for
different categories of users. The category of users I am primarily
thinking about, when working on AppArmor support in Debian, are those
who may not even know what AppArmor is, could not care less about
whether profile X or Y is enforced, and certainly won't decide which
profiles they want to install. I believe these are the vast majority
of Debian users (and if that's not the case yet, then I prefer to work
towards making this real).

I'm happy to welcome contributions that improve UX for other
categories of users, if this does not imply regressions for the
aforementioned category. It does not look like your initial proposal
achieves this, but perhaps a different proposal would :)

>> Apart of this, the way the Debian archive works, having many tiny
>> packages is problematic, so I don't think your proposal would be
>> acceptable by the project. I'm not closing this bug report just yet as
>> I'd like to first better understand what the current setup is lacking
>> for you.

> BTW: Why having many small packages is a problem for debian archive? 

This has been discussed several times on debian-devel@ so the answer
can probably be found there.

Cheers!