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 <[email protected]> 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: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
