All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.