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!