From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>,
openembedded-architecture
<openembedded-architecture@lists.openembedded.org>,
Alexander Kanavin <alexander.kanavin@intel.com>
Subject: Re: [Openembedded-architecture] LAYERSERIES
Date: Fri, 06 Apr 2018 23:00:30 +0100 [thread overview]
Message-ID: <1523052030.2942.40.camel@linuxfoundation.org> (raw)
In-Reply-To: <CA+chaQdiX_GKXAfWJMMc_oZQ5XW-oiuxzxPyMEF2LKZ-rMgDgQ@mail.gmail.com>
On Fri, 2018-04-06 at 20:25 +0200, Martin Jansa wrote:
> FWIW: I've updated some layers with this LAYERSERIES_COMPAT_<layer>
> today and I think it's good idea.
Thanks. I know its late in the cycle but I think it will help.
> It probably won't be enough to stop questions like this:
> http://lists.openembedded.org/pipermail/openembedded-core/2018-April/
> 149696.html
If the layers did have the settings I think it would have fatally
errored out before that. The way this was designed, it will not parse
further that the layer.conf files if mismatch is detected.
> but it's still better to show warning first and then some often
> harder-to-read exception or error log.
Agreed.
> Updating layer.conf in meta-qt5 was a bit more tricky as people tend
> to mix the meta-qt5 branches with different branches of other layers,
> just because their requirements for Qt are often very different than
> for other layers (e.g. many people still using meta-qt5/krogoth with
> Qt 5.6 because of the license, even with much newer morty, pyro,
> rocko, sumo, master branches of other layers and vice versa that
> someone is stuck with krogoth release for whatever reason, but needs
> newer LTS Qt 5.9 from meta-qt5/rocko). So for meta-qt5 I've used
> multiple values for LAYERSERIES_COMPAT_<layer> for combinations I use
> somewhere (so that I cover at least some testing with such uncommon
> combination) and I'm willing to accept more values to it if someone
> really uses another combination regularly. The rest of combination
> (like meta-qt5/krogoth with dizzy, which is usable as described in
> meta-qt5 commits which introduced incompatiblitites, will eventually
> trigger the warning which is fine, because people should be aware
> that they are doing something less tested and that they might to
> implement some work arounds to make it usable).
That sounds good. The system was flexible enough to allow "mismatch",
*if* the layer maintainer supports it. I'm also not expecting people to
backport this to older releases, just to start doing it now so things
improve going forward.
Cheers,
Richard
next prev parent reply other threads:[~2018-04-06 22:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-06 10:37 LAYERSERIES Richard Purdie
2018-04-06 14:16 ` [Openembedded-architecture] LAYERSERIES Trevor Woerner
2018-04-06 15:29 ` Richard Purdie
2018-04-06 18:16 ` Scott Rifenbark
2018-04-06 22:25 ` Richard Purdie
2018-04-06 22:44 ` Scott Rifenbark
2018-04-07 14:13 ` Richard Purdie
2018-04-06 18:25 ` Martin Jansa
2018-04-06 22:00 ` Richard Purdie [this message]
2018-04-06 20:46 ` akuster808
2018-04-06 21:56 ` Richard Purdie
2018-04-14 21:48 ` Trevor Woerner
2018-04-15 21:12 ` Richard Purdie
2018-04-06 18:58 ` Denys Dmytriyenko
2018-04-06 21:52 ` Richard Purdie
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=1523052030.2942.40.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=alexander.kanavin@intel.com \
--cc=martin.jansa@gmail.com \
--cc=openembedded-architecture@lists.openembedded.org \
--cc=openembedded-core@lists.openembedded.org \
/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