Openembedded Core Discussions
 help / color / mirror / Atom feed
From: "Aníbal Limón" <anibal.limon@linux.intel.com>
To: Patrick Ohly <patrick.ohly@intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 3/6] yocto-compat-layer.py: apply test_signatures to all layers
Date: Mon, 29 May 2017 14:26:04 -0500	[thread overview]
Message-ID: <592C75CC.2090708@linux.intel.com> (raw)
In-Reply-To: <1496085537.16923.133.camel@intel.com>

[-- Attachment #1: Type: text/plain, Size: 2639 bytes --]



On 05/29/2017 02:18 PM, Patrick Ohly wrote:
> On Mon, 2017-05-29 at 11:13 -0500, Aníbal Limón wrote:
>> On 05/29/2017 10:32 AM, Patrick Ohly wrote:
>>> Software layers were previously allowed to change signatures, but
>>> that's not desired for those layers either. The rule that a layer
>>> which is "Yocto Compatible 2.0" must not change signatures unless
>>> explicitly requested holds for all kinds of layers.
>>
>> If i understand correctly now a software layer can't change a signature
>> but how do we handle this?, currently if a software layer is added and
>> has bbappends or newer version of a recipe the signature will change.
> 
> We've touched on this topic in the "[Openembedded-architecture] Yocto
> Compatible 2.0 + signature changes" mail thread. I had asked about
> software layers and Richard said "I do think we need to do this [strict
> signature check also for software layers]"

Sorry, i did not see that thread, i need to be more aware on the arch ML. :)

> 
> For .bbappends, the solution from that mail thread is to turn
> DISTRO_FEATURES into overrides and make changes in the .bbappend depend
> on that, or include the .bbappend code only for certain features. That
> reminds me, I still need to turn my prototype code for that into a
> specific patch for bitbake.conf...

Yes, sounds good to me.

> 
> Changing software versions is indeed a bit more problematic. One could
> argue that layers shouldn't fight over who provides a certain recipe in
> the first place. If they do, perhaps the "additional layers" (= the ones
> with lower priority) need to provide explicit .inc files with
> PREFERRED_VERSION assignments without which the overriding recipes
> aren't used?

Yes, so in this case will need to set automatically the preferred
versions to oe-core recipes, and then let the distro layer to change the
preferred version in this way when test a distro layer with oe-core the
signatures not will change only when add the combo of distro layer +
software layer.

> 
> Also remember that this is only a problem for layers who want to be
> "Yocto Compatible 2.0". Other, private layers can simply ignore the
> rules and do what needs to be done.

Agree,

> 
> Alternatively, we can make the stricter checking of software layers
> optional in the tool. Not sure what that'll mean for the "Yocto
> Compatible 2.0" - all layers are created compatible, some more than
> others? ;-}

If we have the decision to include this checking in software layers, i
will go to make it as a default mode with the option to disable it.

Cheers,
Anibal
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2017-05-29 19:26 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-29 15:32 [PATCH 0/6] yocto-compat-layer.py: various enhancements Patrick Ohly
2017-05-29 15:32 ` [PATCH 1/6] yocto-compat-layer.py: avoid adding layers more than once Patrick Ohly
2017-05-29 15:32 ` [PATCH 2/6] yocto-compat-layer.py: tolerate broken world builds during signature diff Patrick Ohly
2017-05-29 15:32 ` [PATCH 3/6] yocto-compat-layer.py: apply test_signatures to all layers Patrick Ohly
2017-05-29 16:13   ` Aníbal Limón
2017-05-29 19:18     ` Patrick Ohly
2017-05-29 19:26       ` Aníbal Limón [this message]
2017-05-29 20:14         ` Christopher Larson
2017-05-30  6:51           ` Patrick Ohly
2017-05-29 15:32 ` [PATCH 4/6] yocto-compat-layer.py: add test_world Patrick Ohly
2017-05-29 15:32 ` [PATCH 5/6] yocto-compat-layer.py: allow README with suffix Patrick Ohly
2017-05-29 15:32 ` [PATCH 6/6] yocto-compat-layer.py: make signature check code reusable Patrick Ohly
2017-05-29 16:15 ` [PATCH 0/6] yocto-compat-layer.py: various enhancements Aníbal Limón
2017-06-27 15:33 ` [PATCH v2 " Patrick Ohly
2017-06-27 15:33   ` [PATCH v2 1/6] yocto-compat-layer.py: avoid adding layers more than once Patrick Ohly
2017-06-27 22:46     ` Christopher Larson
2017-06-28  7:50       ` Patrick Ohly
2017-06-28  9:06         ` Mark Hatle
2017-06-27 15:33   ` [PATCH v2 2/6] yocto-compat-layer.py: tolerate broken world builds during signature diff Patrick Ohly
2017-06-27 15:33   ` [PATCH v2 3/6] yocto-compat-layer.py: apply test_signatures to all layers Patrick Ohly
2017-06-28  9:08     ` Mark Hatle
2017-06-28  9:33       ` Patrick Ohly
2017-06-30  9:17         ` Mark Hatle
2017-06-27 15:33   ` [PATCH v2 4/6] yocto-compat-layer.py: add test_world Patrick Ohly
2017-06-27 15:33   ` [PATCH v2 5/6] yocto-compat-layer.py: allow README with suffix Patrick Ohly
2017-06-27 15:33   ` [PATCH v2 6/6] yocto-compat-layer.py: make signature check code reusable Patrick Ohly

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=592C75CC.2090708@linux.intel.com \
    --to=anibal.limon@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=patrick.ohly@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox