On Tue, Oct 29, 2013 at 3:20 PM, Hans Beckérus <hans.becke...@gmail.com> wrote: > On Tue, Oct 29, 2013 at 2:42 PM, Martin Jansa <martin.ja...@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.ja...@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.ja...@gmail.com _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto