[yocto] DISTRO_FEATURES vs IMAGE_FEATURES

[Colin Helliwell]

> On 26 January 2017 at 02:32 Joshua Watt <jpewhacker at gmail.com> wrote:
> 
> On 01/24/2017 06:40 PM, Takashi Matsuzawa wrote:
> 
> > Hello Yocto.
> > Though it may feel to me matter of taste, is there suggestion on when
> > which of these to use when you need to define your customized feature.
> > 
> > DISTRO_FEATURES seems to be more relaxed, you can define things in
> > your distro conf.
> > IMAGE_FEATURE seems to be more strict, and you need to add your item
> > also as one of the 'validitems', unless you use it through
> > FEATURE_PACKAGES.
> > (Or this is not needed when you use EXTRA_IMAGE_FEATURES?)
> > I've always understood DISTRO_FEATURES to be policy related items about
> > the distro you're creating (e.g. "my distro uses systemd for init", or
> > "my distro uses sysvinit for init", or "my distro support openGL").
> > Because they are more about policy, DISTRO_FEATURES aren't as tied to a
> > specific image. IMAGE_FEATURES are more about the attributes of a
> > particular image (e.g. "include debugging tools like GDB and strace when
> > you build this image"). The two have always been orthogonal in my mind.
> 
> I suppose it would come down to what the features is. If you think your
> new feature is more of a policy based thing, it probably belongs in
> DISTRO_FEATURES. If it is more about controlling something about a
> specific image, than IMAGE_FEATURES is probably more appropriate.
> 

I regularly try to get my head around the same question - haven't been able to find much which clearly differentiates how/when to use which. Maybe that's just because it is somewhat subjective, but the reason for my latest wondering:
I have package X, who's recipe configures the build using PACKAGECONFIG[]. However package Y, on which I want to 'switch', isn't in my distro recipe's DISTRO_FEATURES (e.g. to use ${@bb.utils.contains('DISTRO_FEATURES','Y','Y','--enable-Y=yes',d)} ) , but is instead in my image recipe's CORE_IMAGE_EXTRA_INSTALL.

(How does a package otherwise get itself included into the PACKAGECONFIG[] param?)

In short, I'm looking for the cleanest way to configure X based on whether Y is going to be in the image too (by whatever means it's enabled, distro or image).

Both X and Y are packages which relate to the product - the hardware has a modem therefore kinda needs Y [=ppp] for its intended usage/functionality.
Does this, and this PACKAGECONFIG quandary, make it more of a 'policy' option and therefore more suited to a distro type of thing? 
(I do have a superset development image recipe which adds in tools like strace - and I *can* see in this case that that is more Image than Distro).