DISTRO_FEATURES vs IMAGE_FEATURES

DISTRO_FEATURES vs IMAGE_FEATURES

[Takashi Matsuzawa]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

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

These two just mean one if for DISTRO associated features and another for your image - it is all that?


[-- Attachment #2: Type: text/html, Size: 1106 bytes --]

Re: DISTRO_FEATURES vs IMAGE_FEATURES

[Joshua Watt]

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.

Re: DISTRO_FEATURES vs IMAGE_FEATURES

[Colin Helliwell]

> On 26 January 2017 at 02:32 Joshua Watt <jpewhacker@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).