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

[Robert P. J. Day]

On Mon, 4 Nov 2013, Paul Eggleton wrote:

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

  at the risk of sounding lazy, i'll let someone more comfortable with
this topic tweak that text.

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

  there's more to it than that -- there are a *number* of references
to "etcdir" scattered across a number of layers:

meta-angstrom/recipes-angstrom/angstrom/angstrom-feed-configs.bb:    etcdir = bb.data.expand('${sysconfdir}/opkg', d)
meta-angstrom/recipes-angstrom/angstrom/angstrom-feed-configs.bb:    do_split_packages(d, etcdir, '^locale-(.*)\.conf$', 'angstrom-locale-%s-config', 'Angstrom feed config for the %s locale', extra_depends='', allow_links=True)
meta-openembedded/meta-oe/recipes-extended/zsh/zsh.inc:    --enable-etcdir=${sysconfdir} \
oe-core/meta/conf/documentation.conf:INITSCRIPT_NAME[doc] = "The filename of the initscript as installed to ${etcdir}/init.d. The variable is mandatory and is used in recipes when using update-rc.d.bbclass."
oe-core/meta/recipes-devtools/quilt/quilt/install.patch:-etcdir :=	$(subst /usr/etc,/etc,$(prefix)/etc)
oe-core/meta/recipes-devtools/quilt/quilt/install.patch:+etcdir :=	@sysconfdir@
oe-core/meta/recipes-bsp/pcmciautils/pcmciautils.inc:export etcdir = "${sysconfdir}"
oe-core/scripts/lib/mic/bootstrap.py:            etcdir = _path('/etc')
oe-core/scripts/lib/mic/bootstrap.py:            if not os.path.exists(etcdir):
oe-core/scripts/lib/mic/bootstrap.py:                os.makedirs(etcdir)
openembedded-core-contrib/meta/recipes-devtools/quilt/quilt/install.patch:-etcdir :=	$(subst /usr/etc,/etc,$(prefix)/etc)
openembedded-core-contrib/meta/recipes-devtools/quilt/quilt/install.patch:+etcdir :=	@sysconfdir@
openembedded-core-contrib/meta/recipes-bsp/pcmciautils/pcmciautils.inc:export etcdir = "${sysconfdir}"
yocto-docs/documentation/ref-manual/ref-variables.xml:                    The filename of the initscript as installed to <filename>${etcdir}/init.d</filename>.

so it's not like that's an isolated occurrence. i have no idea *what*
to make of the above. is it all correct other than that single
reference above?

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

  i played with "bb show" to get the following (for the
arbitrarily-chosen recipe zlib):

$ bb show -r zlib PROVIDES
Parsing recipes..done.
# PROVIDES=${PN}
PROVIDES="zlib "
$ bb show -r zlib RPROVIDES
Parsing recipes..done.
RPROVIDES=""
$

where you can see that, for the example zlib recipe, PROVIDES contains
the recipe name but RPROVIDES does not, so i assumed RPROVIDES didn't
automatically provide the package's own name. am i misreading what i'm
seeing above?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================