[yocto] numerous questions about some ref manual variable glossary entries

[Paul Eggleton]

Hi Robert,

On Sunday 03 November 2013 05:53:54 Robert P. J. Day wrote:
>   wasn't sure what to do about some of these so i'd appreciate some
> clarification. and away we go, mostly in alphabetical order ...
> 
> http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-BBLAY
> ERS_NON_REMOVABLE
> 
>   that entry *really* implies you need the meta-yocto and
> meta-yocto-bsp layers for a successful build, which clearly isn't true
> as lots of layers work with simply oe-core. can/should that
> explanation be reworded to not be quite so emphatic?

Yes, agreed. The entry should mention that this variable is only actually used 
by Hob as well.

> http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-INITS
> CRIPT_NAME
>
>   reference to ${etcdir} ... how exactly does that differ from
> ${sysconfdir}? i've always understood that developers should use
> ${sysconfdir} in their recipe files.

I don't know where this came from but it is wrong. It should say ${sysconfdir} 
instead.
 
> http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-NO_RE
> COMMENDATIONS
> http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-PACK
> AGE_EXCLUDE
> 
>   both of those claim no support for DEB packaging, is that still
> true? i still don't know enough python to check the actual code but
> i'm getting there.

Yes, these were only introduced recently and AFAIK this is still the case.

> http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-RPROV
> IDES
> 
>   claims that a package's own name is already implicitly provided in
> its RPROVIDES list. doesn't seem that way -- it's true for PROVIDES,
> but doesn't seem true for RPROVIDES. thoughts?

It was me who got Scott to add this - I did so after seeing a number of people 
trying to do RPROVIDES_${PN} = "recipename" in the hope of fixing some problem 
they were having; but this won't do anything. What makes you think it isn't 
the case?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre