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

[Mark Hatle]

On 6/9/16 7:49 AM, Otavio Salvador wrote:
> 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.

Detection of the collision, and then marking it as a fork would be a benefit in
my mind to users looking at the index.  (Now, how do we know it's a fork? not
sure..)  but collision w/o it being a fork is 'bad'.  Collision with it being a
fork is 'select one or the other'.

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

Exactly.. a lot of my desire for this comes from Toaster / index integration.
After seeing the demonstration at ELC (San Diego) and seeing how some of the
data, dependencies, etc is out of date..  I really want a way to make sure the
data is as "up to date" as possible -- and information or dependency errors can
be submitted back to the layer as simple patches, and 'fix' the index/toaster
integration automatically.

--Mark