[Openembedded-architecture] layer.conf and layerindex change proposal

[Otavio Salvador]

On Thu, Jun 9, 2016 at 2:04 AM, Paul Eggleton
<paul.eggleton at linux.intel.com> wrote:
> 3) Add a LAYERPROVIDES or similar so we have a way of avoiding a flag day on
> renaming the collections to match the layer name.

What if someone forks a layer, for example:

 meta-fsl-arm -> meta-fsl-arm-myfork

Any layer which depends on the first ought to work with the second.
Does the collection name to be the same here? This is a valid and real
use-case. For layer index we must avoid duplications or show them as
alternative implementations.

...
> I'm not totally sold on LAYERRECOMMENDS, though I have often been frustrated
> at being forced to add a dependent layer when in fact that dependency exists
> only to satisfy a DEPENDS in one or two recipes that I don't even need to
> build, so it's possible that could help in that situation - but it relies on
> the layer maintainer applying it (and agreeing that it's the right thing to do
> vs. LAYERDEPENDS). Conceivably you could also use LAYERRECOMMENDS to augment
> missing DEPENDS errors e.g. "Nothing PROVIDES xyz - perhaps you need to add
> layer meta-a, meta-b or meta-c to satisfy this?"

I like the idea. Also the dynamic enablement of recipes with the
availability of collections can also use this. We use this for
meta-fsl-arm for chromium and other recipes.

> As for LAYERSUMMARY, LAYERDESCRIPTION and LAYERHOMEPAGE, we could certainly
> add these although LAYERHOMEPAGE doesn't match up directly with anything we
> have in the layer index (instead we have usage information and the web link to
> the repo, and the latter is mostly set automatically based on the git URL if
> it's a host we know about, e.g. github or git.yoctoproject.org). It's less
> clear to me how useful these are though apart from to save a little time on
> submitting to the layer index (or adding to a private layer index instance).
> One problem it will create is that right now entering the summary /
> description are mandatory when submitting to the layer index, but presumably
> if the information was in layer.conf people would want that to be optional in
> the submission form - but then it's optional in the layer.conf as well and we
> won't actually know whether it's set until we parse the layer, which doesn't
> happen until after the layer is manually published (for security and keeping
> some measure of order in the database.)

I think those ought to be required. Having them on code easy the
improvement and maintenance. Also Toaster and other tools can use this
info as well.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750