Hi,

I've re-read the bug log and taken a step back. Here's some context
and a proposal. Please provide input/opinions; especially Ubuntu
people are welcome to comment: I want to do something that works for
them as well (saying "we don't care much about this package, do
whatever you want and we'll pull it as-is" is a valid option).

Context: this is about the apparmor-profiles package, that has no
reverse-dependency, so this whole thing is not such a big deal (users
won't be affected unless they voluntarily install this package).
This package ships policy in /etc/apparmor.d/ (loaded, in so-called
complain mode i.e. not enforced except 'deny' rules), and some more in
/usr/share/doc/apparmor-profiles/extras/ (not loaded at all).

IMO the primary short-term goal of shipping this package at all in
Debian/Ubuntu is to encourage enthusiast AppArmor users on Debian,
Ubuntu and derivatives to improve WIP, shared profiles that live in
the upstream AppArmor bzr repo, instead of writing their own from
scratch. As Antoine explained, we currently do a poor job at this with
this package.

And the long-term goal is that eventually, some of these shared
profiles might become good enough to be shipped in the apparmor
package and enforced by default (and others should simply dropped from
Debian-based distros if nobody cares enough to make them work on
Debian and maintain them proactively).

I propose we pick some low-hanging fruits to better achieve these
goals without hindering our other, perhaps more important WIP efforts:

1. Rephrase the description of this package to better express what
   users are entitled to expect from the policy it ships.

   (Giving the package a less misleading name would be even better,
   but that would require more work spread over many wikis/doc pages
   so let's not bother for now.)

2. Install *all* the profiles shipped by this package to
   /etc/apparmor.d/, set it in complain mode.

   (Once it's been clarified what this package is about, let's smooth
   the "get started with contributing to these profiles" process.)

3. Take advantage of reportbug mechanisms (as suggested by Antoine) to
   help users report bugs and contribute patches about this policy to
   better places than the Debian BTS.

4. Go back to the broader "have better tools & processes to do
   cross-distro profiles maintenance" topic.

Cheers,
-- 
intrigeri

Reply via email to