[yocto] SRCREV how is it supposed to work?

[Hans Beckérus]

On Tue, Oct 29, 2013 at 3:20 PM, Hans Beckérus <hans.beckerus at gmail.com> wrote:
> On Tue, Oct 29, 2013 at 2:42 PM, Martin Jansa <martin.jansa at gmail.com> wrote:
>> On Tue, Oct 29, 2013 at 02:27:30PM +0100, Hans Beckérus wrote:
>>> On Tue, Oct 29, 2013 at 12:00 PM, Martin Jansa <martin.jansa at gmail.com> wrote:
>>> > On Tue, Oct 29, 2013 at 12:46:18PM +0100, Hans Beckérus wrote:
>>> >> Hi. I am wondering if we are using SRCREV wrong somehow.
>>> >> Is it expected that if we use SRCREV = "${AUTOREV}", that any changes
>>> >> to the remote should be automatically detected and downloaded/fetched?
>>> >> I can no see that this is actually what happens. Any changes made to
>>> >> the remote still need to be manually fetched or indirectly by stepping
>>> >> the recipe revision.
>>> >> Are we using SRCREV wrong or is this actually the way it is supposed
>>> >> to work? Also, is there some way to force a download to me made every
>>> >> single time by a recipe,
>>> >> irrespective of if the remote changed or not?
>>> >
>>> > It's supposed to run git ls-remote while parsing to get latest revision
>>> > in remote repo and then rebuild the package because of SRCPV change in
>>> > PV, are you using something like:
>>> >
>>> > PV = "1.0+git${SRCPV}"
>>> >
>>> > ?
>>> >
>>> Nope. I did not know we had to use PV. Sounds like we need to in the
>>> general case. But in this case,
>>
>> You need to reference it somewhere, if you were using multiple git repos
>> in SRC_URI you probably need to define SRCREV_foo = "${AUTOREV}" for all
>> of them (where foo is from name=foo param for each repo).
>>
> Sure.
>
>>> we actually do not have versions on the package itself since it is
>>> simply a container for several other binary packages merged into one
>>> binary file.
>>> So our "package" is downloading packages from several git repos,
>>
>> "package" -> "recipe"
>>
> Yea, yea! :)
>
>>> stored in different folders using 'destsuffix'.
>>> Would it be ok to simply set PV = "${SRCPV}" ? I guess this will
>>
>> SRCPV is sortable and consistent only with shared persistent PR server is used
>> across all builders - if that's not the case it's safer to prefix SRCPV
>> with some manually maintained version.
>>
> No problem. That is doable.
>
>>> result in a new target folder for each changed remote? And will this
>>> work when referring to several git repos in SRC_URI?
>>
>> You'll need to define SRCREV_FORMAT and name parameter for each repo in
>> SRC_URI.
>>
> Now I am not following you :( name I understand, but what is SRCREV_FORMAT?
>
>>> Since changes are expected to happen frequently some sort of
>>> garbage-collection function is needed to get rid of all the obsolete
>>> package trees. IIRC was there not an option for this somewhere?
>>
>> Maybe you're talking about rm_work, but I'm not sure what you mean by
>> package trees.
>>
> Maybe it was rm_work, by "package trees" I mean whatever is unpacked
> from the fetch.
>

I have seen recipes that defines PV = "xyz+git${SRCPV}" and then
SRCREV to a specific tag instead of ${AUTOREV}.
Is that not contradictory? Or is it simply that the author of that
recipe wished to have a git tag automatically added to the version
string?
Are there any specific cases when that approach is to prefere?

Thanks.
Hans

>> --
>> Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com