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

[Fabian Grünbichler]

On Thu, Dec 07, 2017 at 10:08:54AM +0100, intrigeri wrote:
> 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 :)

yes, we know what being a derivate means, and we do occasionally work
around issues or even just different update policies by carrying our own
backported or patched packages for a release cycle or two, even when not
directly related to our core technologies.

when avoidable, we don't for obvious reasons - which is why we try to
get fixes and features upstream whenever they make sense. given the now
more active situation regarding AA in Debian, we'll pay closer attention
to developements to hopefully catch potential future problems early.

I don't expect Debian maintainers to know and care about all derivates
and their usage of various packages ;)

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

I was expecting this, but asking does not hurt when one is not familiar
with specifics of (release) policies ;)

> 
> > 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?

sounds like a plan, I'll re-spin my patch later today.