In ticket: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7306. It was said that PV needs to contain the actual revision. I followed the idea from the manual: http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html#var-DEFAULT_PREFERENCE - use a versioned recipe by default foobar_1.0.bb - add foobar_git versioned recipe with DEFAULT_PREFERENCE=-1 in local.conf I then override the PREFERRED_VERSION PREFERRED_VERSION_foobar = "git" If a add the SRCREV to PV, I have to update the local.conf each time the repository head changes, since the version is now e.g. gitr502+2621bc6. The version is not "git" at all When not addinng the SRCREV to the name I run into the problem as in ticket 7306 above: This is because since all task stamps are still valid. None contains the git revision. With PV containing the git revision, this worked since the stamp filename (=siginfo files) contained PV, hence it was recreated whenever the src repository changed I worked around this problem like this: +python () { + git_rev=bb.fetch2.get_srcrev(d).split('+')[1] + d.setVar('GIT_REV', git_rev) +} + +## force-add the git revision to the sstate siginfo file +# previously PV contained GITPKGV, hence the siginfo filename itself contained +# the git revision. But then we can't set PREFERRED_VERSION statically, because +# the PV is not constant. PV=GITPKGV=gitrXXX-YYYYYYYY +do_fetch[VARDEPS] += "${GIT_REV}"
FYI: simplified workaround to just this +do_fetch[VARDEPS] += "${SRCPV}"
Did you try: PREFERRED_VERSION_foobar = "git%" ?
yes, that solved the problem, sorry the noise. I wasn't aware I could use patterns to set the preferred version.
No problem, marking resolved.
I must have made an error while testing before, retested again and it seems patterns don't work, I tested with yocto-2.4: NOTE: Started PRServer with DBfile: /home/afenkart/dSS/dss-oe/poky-rescue-devel-build/cache/prserv.sqlite3, IP: 127.0.0.1, PORT: 35763, PID: 2461 NOTE: preferred version %git% of rescue-system not available (for item rescue-system) NOTE: versions of rescue-system available: 1.1.0 1.1.0+gitrAUTOINC+e695223c1e NOTE: Resolving any missing task queue dependencies NOTE: preferred version %git% of rescue-system not available (for item rescue-system-dev) NOTE: versions of rescue-system available: 1.1.0 1.1.0+gitrAUTOINC+e695223c1e NOTE: preferred version %git% of rescue-system not available (for item rescue-system) NOTE: versions of rescue-system available: 1.1.0 1.1.0+gitrAUTOINC+e695223c1e the recipe part: inherit gitpkgv PV = "1.1.0+gitr${SRCPV}" PKGV = "1.1.0+gitr${GITPKGV}" PR = "r0" site.conf: -PREFERRED_VERSION_rescue-system = "git" +PREFERRED_VERSION_rescue-system = "%git%"
Hang on - if what you are trying to match is git<something> why are you using "%git%" and not "git%" as I suggested? Does that make a difference?
Marking NEEDINFO - Andreas, could you answer my most recent question? Thanks.
I used both ways, first git% then, since the log output has a leading prefix, I used %git% just as a try. Shall I retry with another pattern?
I believe you want "1.1.0+git%" here after re-reading above.
Sorry was not online last week. I rechecked with: -PREFERRED_VERSION_rescue-system = "git" +PREFERRED_VERSION_rescue-system = "1.1.0+git%" And that indeed works: - prefers the _git.bb recipe over the _1.1.0.bb recipe - picks up changes when the upstream head is changed - the generated package can be depended on from a taks/rootfs recipe So far that seems to solve all my problem, the only sour taste to remain is that I must not forget to update the site.conf/local.conf whenever I bump the base version (=1.1.0 -> 1.2.0). But that will produce a bitbake warning, saying that recipe 1.1.0-gitrxxx is not found. I see that you already updated the documentation and clarified the point: http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html#var-PREFERRED_VERSION
It appears the NEEDINFO was answered.
OK, great, I think we can consider this resolved unless you have further issues. I have however filed bug 12390 to cover the issue that % only works at the end of an expression - either we need to make it work anywhere, or properly document it as only working at the end since it appears we aren't currently mentioning that.