[pkg-apparmor] Bug#883682: don't install features-file as conffile for easier overriding

[intrigeri]

Hi,

Fabian Grünbichler:
> On Thu, Dec 07, 2017 at 08:47:52AM +0100, intrigeri wrote:
>> > I am not sure whether we are the only derivative/downstream/.. affected
>> > by this change, but it has the potential to break a lot of setups using
>> > their own (more recent / patched to support more of AA) kernel and AA
>> > profiles on top of Stretch..
>> 
>> With my AppArmor in Debian maintainer hat, I've never heard of people
>> running this kind of things in production until you reached out to me.
>> So these people might exist, but they're not talking to me. Thanks to
>> you I'm now aware of this use case and we can work together to support
>> it better :)

> I guess we do run a bit of an unusual setup here:

Indeed. I'm glad you're aware that we can't support this in Debian
without collaboration from your sid, and that you're actually helping
Debian help you :)

> https://bugs.launchpad.net/apparmor/+bug/1736896

> if such a feature becomes available soon, do you think it would be
> viable to move the feature pinning directive into such a snippet file,
> instead of or in addition to moving the feature file to /usr/share/foo?

See below.

> if so, would that be something that is in scope to be cherry-picked for
> Stretch in a point release?

No. Adding features is definitely out of scope for stable updates in
general, and after the mess I've created with my last stretch-pu,
I want to be very careful with my next stable update requests in order
to regain some trust from the release team.

> if the answer is yes, I would try to avoid moving stuff twice and focus
> on this snippet mechanism for now, and only falling back to moving the
> features file (and diverting it downstream) as a last resort. otherwise,
> moving the features file to a non-conffile location should be done
> sooner rather than later, and the snippet mechanism can just be
> introduced as part of the next AA upstream release (whenever that
> happens) and used to override the features-file directive downstream
> whenever it becomes available, replacing the divert.

I think we should:

 - move the features file to a non-conffile location ASAP: not only it
   makes little sense for it to be a conffile, but if I manage to get
   a pinned feature set in Stretch at some point you'll want this in
   order to divert the features file; I am finalizing a new upload
   to sid as we speak, but I can wait a bit for you to finish your
   patch so I can include it. Ideally I would like to upload today,
   worst case tomorrow, to fix #883703 ASAP.

 - leave the default features-file= setting in parser.conf

 - add the config snippet mechanism upstream and whenever it's
   available in Debian, you can use it to override the default
   value of features-file= (and you can drop the diversion)

What do you think?

Cheers,
-- 
intrigeri