Appends end up shoved into a dictionary (self.appendlist in the cooker) by base name, which is the append name with 'bbappend' replaced with 'bb'. This means that systemd_% and systemd_219 end up as two different entries in this dict. So within a given basename, layer priority order is retained, but between the two, the order is non-deterministic, and of course the order between the two sets of appends is lost, since they're processed first one, then the other. I expect we should probably do the mapping of % to actual recipe up front rather than postponed to get_file_append(), which would avoid the need to index the appends the way we are now. This bug leads to sstate reuse problems, as the changing append order can change the order of entries in word-separated / list-style variables (e.g. SRC_URI).
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=3cb87724a5b21550e99c18e97b665d6604bb2fa9
Hello, I tested this bug by having a foo_0.1.1.bb in a layer and two .bbappend files each on their own layer: cosscat@ubnt:/media/poky/3poky$ ls meta-layer?/recipe*/ meta-layer1/recipes-test/: foo_0.1.1.bb meta-layer2/recipes-test/: foo_0.1.1.bbappend #this one contains A += "1" meta-layer3/recipes-test/: foo_%.bbappend # this one contains A += "2" Ran 100 times bitbake foo -e | grep 'A=" 1 2"' and all in all cases, the result is the same: cosscat@ubnt:/media/poky/3poky/build$ for i in $(seq 100) > do > bitbake foo -e | grep 'A=" 1 2"' > done A=" 1 2" # 100 times ... Marking bug as verified. Costin