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). > 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" > 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. > 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. > 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. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
_______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto