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

Paul Eggleton paul.eggleton at linux.intel.com
Mon Nov 4 07:46:19 PST 2013


On Monday 04 November 2013 10:40:45 Robert P. J. Day wrote:
> On Mon, 4 Nov 2013, Paul Eggleton wrote:
> > On Sunday 03 November 2013 05:53:54 Robert P. J. Day wrote:
> > > http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-I
> > > NITS 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:expo
> rt 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?

None of those are trying to access an "etcdir" variable defined system-wide. 
There is no such variable, and most of the examples are unrelated to 
eachother.

> > > http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-R
> > > PROV 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?

This is what I meant by "implicit". That doesn't mean printing out the 
variable will show that it explicitly contains the value.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



More information about the yocto mailing list