From: Mike Looijmans <mike.looijmans@topic.nl>
To: <openembedded-devel@lists.openembedded.org>
Subject: Re: Correct versioning of unversioned source in git
Date: Fri, 14 Mar 2014 12:53:59 +0100 [thread overview]
Message-ID: <5322EDD7.1050206@topic.nl> (raw)
In-Reply-To: <2224360.gaE7z3Uyox@peggleto-mobl5.ger.corp.intel.com>
On 03/13/2014 12:54 PM, Paul Eggleton wrote:
> On Thursday 13 March 2014 12:17:40 Koen Kooi wrote:
>> Op 13 mrt. 2014, om 12:14 heeft Paul Eggleton
> <paul.eggleton@linux.intel.com> het volgende geschreven:
>>> On Thursday 13 March 2014 12:09:21 Koen Kooi wrote:
>>>> Op 13 mrt. 2014, om 11:45 heeft Paul Eggleton
>>>
>>> <paul.eggleton@linux.intel.com> het volgende geschreven:
>>>>> On Thursday 13 March 2014 10:59:38 Koen Kooi wrote:
>>>>>> Tomas Novotny schreef op 13-03-14 10:08:
>>>>>>> there is a recipe sunxi-board-fex in meta-sunxi layer. That recipe
>>>>>>> fetches sources from unversioned git which contains definitions of
>>>>>>> some
>>>>>>> boards (in fact it is something like a store). I'm not sure with
>>>>>>> correct
>>>>>>> versioning in OE. Is that: PV = "1.0+git${SRCPV}" SRCREV =
>>>>>>> "<some_gitrev_I_want>" correct? Will be change of SRCREV (only)
>>>>>>> catched
>>>>>>> by build system (I'm curious how OE handles age of the rev in git)? Or
>>>>>>> do
>>>>>>> I need to raise PV to 1.1 and so on with every change to SRCREV?
>>>>>>
>>>>>> The answer changes if you have more than one buildhost. If you have
>>>>>> only
>>>>>> one buildhost and don't care about other people rebuilding the exact
>>>>>> same versions, 1.0+git${SRCPV} will work.
>>>>>>
>>>>>> If you have more than one buildhost and/or care about other people
>>>>>> rebuilding the exact same, you'll need to increase PR (or PV) everytime
>>>>>> SRCREV changes. That will still cause some discrepancies if someone
>>>>>> rebuilds after >1 SRCREV change, but upgrade paths should work when
>>>>>> increasing PV (not with PR!).
>>>>>
>>>>> Why not with PR?
>>>>
>>>> because SRCPV in in PV, not PR
>>>
>>> Right, but if you're using the PR server, that also stores the
>>> incrementing
>>> number at the start of SRCPV; PR may also increment when SRCREV changes as
>>> well (not sure on the latter). The PR server ought to be used if you care
>>> about this sort of thing.
>>
>> Only if your PR server is publicly available *and* you have network access
>> during the build. There is currently no workable way to get versioning info
>> to users trying to rebuild something. The closest I've been to a solution
>> is to ship prserv-tool exports in git.
>
> If you're saying you want something that doesn't require network access, gets
> the right answer for all users *and* automatically increments when something
> changes - those are conflicting requirements...
"gitpkgv" from mete-openembedded has been doing a good job at that for me in
several projects. It just counts the number of git commits and uses that as
counter. Everybody thus sees the same number, versions are incremental, and no
server access needed during build.
My only wish would be that this were in oe-core.
Met vriendelijke groet / kind regards,
Mike Looijmans
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax: (+31) (0) 499 33 69 70
E-mail: mike.looijmans@topic.nl
Website: www.topic.nl
Please consider the environment before printing this e-mail
next prev parent reply other threads:[~2014-03-14 11:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-13 9:08 Correct versioning of unversioned source in git Tomas Novotny
2014-03-13 9:59 ` Koen Kooi
2014-03-13 10:45 ` Paul Eggleton
2014-03-13 11:09 ` Koen Kooi
2014-03-13 11:14 ` Paul Eggleton
2014-03-13 11:17 ` Koen Kooi
2014-03-13 11:54 ` Paul Eggleton
2014-03-13 13:13 ` Koen Kooi
2014-03-14 11:53 ` Mike Looijmans [this message]
2014-03-13 21:15 ` Tomas Novotny
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=5322EDD7.1050206@topic.nl \
--to=mike.looijmans@topic.nl \
--cc=openembedded-devel@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 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.