From: Martin Jansa <martin.jansa@gmail.com>
To: "Burton, Ross" <ross.burton@intel.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] libcomps: put PV in filename
Date: Tue, 26 Mar 2019 12:01:58 +0100 [thread overview]
Message-ID: <20190326110158.GB1929@jama> (raw)
In-Reply-To: <CAJTo0LaFy7s7gjzxxB9yBn6613wCz=Jp=LtVbz8UsDxk1Ls58A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2372 bytes --]
On Tue, Mar 26, 2019 at 10:32:07AM +0000, Burton, Ross wrote:
> On Tue, 26 Mar 2019 at 10:20, Martin Jansa <martin.jansa@gmail.com> wrote:
> > http fetcher won't (usually) fetch different version just by changing 1
> > variable inside the recipe and vice versa, renaming the recipe won't
> > fetch different SRCREV with git.
>
> Sure it will. gcc_http.bb sets PV=8.3.0 in the recipe, and SRC_URI
> uses ${PV}. The only catch is that http fetches have a secondary
> layer of transport checksums that git doesn't have.
I'm sorry, that's not what I meant.
git fetcher fetches whatever SRCREV is defined in the recipe, no matter
what PV says, I've seen enough recipe upgrades which just renamed the
recipe to have new version in filename updating SRCREV and even claimed
that the upgrade was properly tested, because nothing got broken :).
In webOS we got a bit further and PV+SRCREV are defined in one variable
WEBOS_VERSION and do_fetch qa check tests that the SRCREV points to
matching annotated version tag in the component.
> > If someone wants to update SRCREV in libcoms to be 10 commits behind
> > 0.1.10, is he expected to rename the recipe back to libcomps_git.bb and
> > re-add the PV variable (with new +git${SRCPV} suffix)?
>
> Yes. The recipe ships a release. If the recipe is changed from
> shipping a tested and maintainer approved release to a git snapshot,
> that definitely should not be trivial.
Next time someone needs to include few bugfixes from stable branch
included just after the release, should he update the SRCREV or add them
as .patch files?
> > I got used to "+git${SRCPV}" being dropped when the SRCREV matches
> > exactly the git tag, but renaming the recipe and removing the PV seems
> > too much, what is the benefit of doing that? It's not for clarity or
> > easier maintenance (at least for me), because PV next to SRCREV makes
> > much more sense to me (and helps people not to forget updating both at
> > the same time).
>
> For clarity and consistency: by convention recipes that ship releases
> put the PV in the filename.
FWIW: in webOS we don't use any version in filename, most recipes are
called just PN.bb and it works fine as well for us, less renames and
version consistently defined inside the recipes.
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]
next prev parent reply other threads:[~2019-03-26 11:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-25 23:44 [PATCH] libcomps: put PV in filename Ross Burton
2019-03-26 1:39 ` Khem Raj
2019-03-26 10:00 ` Burton, Ross
2019-03-26 10:20 ` Martin Jansa
2019-03-26 10:32 ` Burton, Ross
2019-03-26 11:01 ` Martin Jansa [this message]
2019-03-26 11:06 ` Burton, Ross
2019-03-26 10:42 ` Adrian Bunk
2019-03-27 13:33 ` Martin Jansa
2019-03-27 14:03 ` Adrian Bunk
2019-03-27 14:20 ` Martin Jansa
2019-03-26 18:12 ` Khem Raj
2019-03-29 18:45 ` Böszörményi Zoltán
2019-03-29 18:46 ` Böszörményi Zoltán
-- strict thread matches above, loose matches on Subject: below --
2019-03-04 11:58 Ross Burton
2019-03-04 15:12 ` Richard Purdie
2019-03-04 16:33 ` Burton, Ross
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=20190326110158.GB1929@jama \
--to=martin.jansa@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=ross.burton@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