| Summary: | Wrong package version is required if two version of the same recipe was built | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Felipe Ferreri Tonello <ftonello> |
| Component: | core | Assignee: | Richard Purdie <richard.purdie> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | meta.mr.watcher, meta.watcher |
| Version: | 1.4 | ||
| Target Milestone: | 1.6 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
This seems to be more of a usage question/bug, but I'm not sure we have a good category for that. Dumping in core for now. Has this been discussed on the mailing list? This is not a usage question. It's a real bug. It only works in I do bitbake -c cleanall libfoo. I noticed that even deleting the tmp/ directory, it still happens. So perhaps the bug is in the cache database, or something. Initially I wondered if this was related to 5094 and 5067 since they also involve multiple providers but it might not be. Which version of poky/oe-core are you using? The key question is whether the recipes which RDEPEND on libfoo repackage when you change the version of libfoo. They should and they should then get the right dependency information. If they do repackage and get the wrong information that gives us a clue where to start to look for a problem. Equally, if they don't repackage, that is a different issue. Either way, it is hard to debug hypothetical examples. Is there a way we can make a real world example test case? (In reply to comment #3) > Initially I wondered if this was related to 5094 and 5067 since they also > involve multiple providers but it might not be. > > Which version of poky/oe-core are you using? I'm using dylan (9.0) it is also reproducible with dylan 9.0.1. (In reply to comment #4) > The key question is whether the recipes which RDEPEND on libfoo repackage > when you change the version of libfoo. They should and they should then get > the right dependency information. > > If they do repackage and get the wrong information that gives us a clue > where to start to look for a problem. > > Equally, if they don't repackage, that is a different issue. > > Either way, it is hard to debug hypothetical examples. Is there a way we can > make a real world example test case? Yes, I understand, it's hard to debug it. Well, easy way to reproduce it is: Let say a libfoo_git.bb has PV = "git${SRCPV}" and SRCREV = "${AUTOREV}". What I do to force the recipe always to rebuild from HEAD of master is to add a random comment in do_fetch, so the sstate cache will get invalidate. do_fetch_prepend() { # ${@invalidate_sstate_cache()} } Where this invalidate_sstate_cache() basically returns a random number. I do this based on section 3.2.4.2 of Yocto's 1.4 poky reference manual. Steps to reproduce: 1. Build an image that installs an app that RDEPENDS on libfoo. 2. Later commit something in libfoo, thus changing its master HEAD. 3. Build the image again. This should be enough. You will notice that libfoo was recompiled but do_rootfs will fail because it will try to install libfoo HEAD~ (old) version. If you do *bitbake -c cleanall libfoo* it works. Ok, firstly sorry its taken me as long to get to this. What would have helped is some way of reproducing the problem. I've tried to reproduce this issue as follows using poky master.
First, I make a checkout and ran "MACHINE=qemux86 bitbake avahi".
$ dpkg-deb -I tmp/deploy/ipk/i586/avahi-daemon* | grep Depends:
Depends: libdaemon0 (>= 0.14), libcap2 (>= 2.22), libavahi-core7 (>= 0.6.31), libdbus-1-3 (>= 1.6.18), base-files, libavahi-common3 (>= 0.6.31), libc6 (>= 2.19), shadow, libexpat1 (>= 2.1.0), base-passwd
So we can see that avahi-daemon depends on libdaemon verison 0.14.
I then added a git libdeamon recipe which is a copy of the 0.14 version but with:
LIC_FILES_CHKSUM = "file://LICENSE;md5=3f160358b580634d8dd2904c9f575c1d \
file://libdaemon/daemon.h;beginline=9;endline=21;md5=f3384272745f86d34ce2902aa834c6e2"
SRC_URI = "git://git.0pointer.de/libdaemon"
PV = "0.14+git${SRCPV}"
SRCREV = "${AUTOREV}"
S = "${WORKDIR}/git"
I then ran "MACHINE=qemux86 bitbake avahi" and watched libdaemon rebuild. Afterwards:
$ dpkg-deb -I tmp/deploy/ipk/i586/avahi-daemon* | grep Depends:
Depends: libdaemon0 (>= 0.14+git0+0630da04e5), libcap2 (>= 2.22), libavahi-core7 (>= 0.6.31), libdbus-1-3 (>= 1.6.18), base-files, libavahi-common3 (>= 0.6.31), libc6 (>= 2.19), shadow, libexpat1 (>= 2.1.0), base-passwd
so the dependency of libdaemon is changing correctly to the new version.
As far as I can tell, what you describe therefore works on master. If you're still having the issue, can you explain what I'd need to do using something like the above test case to reproduce the problem? If so, please reopen this but I can't help unless I can reproduce the problem.
|
I have two versions of recipes for the same library: * libfoo_1.0.bb * libfoo_git.bb To make sure my normal build uses the specific version, instead of git, I added a DEFAULT_PREFERENCE = "${@use_git_or_not()}" in the git recipe. Whereas the use_git_or_not() function basically checks for a environmental variable and returns -1 or 1. This approach works well. When I do a regular build, bitbake uses the specific version. When I want to do a nightly build, I call bitbake with USE_GIT variable set, and it calls all "git" recipes. Some other recipes RDEPENDS on libfoo. The problem here is that after doing a regular build (using specific version) I did a nightly build (using git) and the package dependency for these other recipes that RDEPENDS on libfoo are wrong. They always set the package dependency version to 1.0 instead of git... . So instead of having a package dependency on libfoo >= git... it's libfoo >= 1.0, even though I'm building the git recipe (I can check that with bitbake -s).