Re: SRCREV how is it supposed to work?

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2547 bytes --]

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@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.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]