From: "Sapp, Randolph" <rs@ti.com>
To: Denys Dmytriyenko <denis@denix.org>
Cc: <denys@ti.com>, <reatmon@ti.com>, <detheridge@ti.com>,
<meta-ti@lists.yoctoproject.org>, <k-bhargav@ti.com>
Subject: Re: [EXTERNAL] Re: [EXTERNAL] Re: [meta-ti] [master/kirkstone][PATCH] all: Graphics recipe overhaul
Date: Fri, 20 Jan 2023 17:24:37 -0600 [thread overview]
Message-ID: <115TOR.S0E6VS3VSAUV@ti.com> (raw)
In-Reply-To: <20230120221120.GR22689@denix.org>
On Fri, Jan 20 2023 at 05:11:20 PM -0500, Denys Dmytriyenko
<denis@denix.org> wrote:
> Well, there are pros and cons to both approaches. And I would be more
> inclined
> to agree with you that it is necessary to copy over the entire Mesa
> recipes,
> if you were trying to apply patches on top of the upstream version.
> But, you
> are completely changing SRC_URI and SRCREV anyway to point to your
> own tree,
> so it doesn't matter very much what underlying version of the recipe
> you start
> with. I do believe it would just work for the master with 22.2.3
> version.
> Sure, recipes sometimes change significantly and break your bbappend,
> but
> that's when it will be the time to consider carrying the full set of
> older
> version, sometime in the future.
>
> As an example, we've been carrying bbappends in meta-ti for upstream
> optee and
> trunsted-firmware-a recipes from meta-arm - sometimes we fall behind
> and stick
> to an older version, but sometimes we update to a newer version
> earlier than
> upstream. That's been working for several years and quite successful
> for the
> most part...
>
> On the other side of the spectrum, there's ltp-ddt recipe that is
> based on top
> of the upstream ltp recipe of a specific version. It's not exactly a
> bbappend,
> but close enough. When upstream upgrades to a newer version, we end
> up copying
> the specific previous version locally side-by-side. Later, when we
> rebase
> ltp-ddt and catch up with the ltp version upstream, we can remove the
> duplicate.
>
> In other words, *IF* we end up duplicating Mesa recipes locally, I'd
> argue we
> should keep them unmodified and apply any modifications through
> bbappend. If
> needed, you can make it version-specific, e.g. mesa_22.0.%.bbappend.
> That way
> in kirkstone you only need this bbappend, but in langdale/mickledore
> you may
> end up having a local copy of *unmodified* mesa_22.0.3.bb from
> kirkstone along
> with this mesa_22.0.%.bbappend on top. In other words - if you
> refrain from
> modifying the local duplicates of upstream files and keep them
> intact, it
> would be much easier to maintain long term...
Well what do you recommend? Version pinning (through the copy in
meta-ti) in addition to a bbappend, or just a version globed bbappend?
next prev parent reply other threads:[~2023-01-20 23:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-19 20:40 [master/kirkstone][PATCH] all: Graphics recipe overhaul Randolph Sapp
2023-01-20 18:26 ` [meta-ti] " Denys Dmytriyenko
2023-01-20 18:50 ` [EXTERNAL] " Sapp, Randolph
2023-01-20 22:11 ` Denys Dmytriyenko
2023-01-20 23:24 ` Sapp, Randolph [this message]
2023-01-23 22:24 ` Denys Dmytriyenko
2023-01-23 13:55 ` Andrew Davis
[not found] ` <173C27F35DB2D18B.15760@lists.yoctoproject.org>
2023-01-23 17:13 ` [EXTERNAL] " Sapp, Randolph
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=115TOR.S0E6VS3VSAUV@ti.com \
--to=rs@ti.com \
--cc=denis@denix.org \
--cc=denys@ti.com \
--cc=detheridge@ti.com \
--cc=k-bhargav@ti.com \
--cc=meta-ti@lists.yoctoproject.org \
--cc=reatmon@ti.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.