Fixing package dependencies across recipe versions?

Heinz Wrobel



In my layer I have two older versions of glibc in addition to the 2.35 provided by kirkstone, and a the global conf for the build directory sets GLIBCVERSION to select which one to use.


The problem is that they don’t all provide exactly the same thing and that older version appear to influence newer versions, causing warnings.

2.27 and 2.31 build libsegfault, but 2.35 doesn’t anymore. If I prefer 2.35, then I get warnings like:


WARNING: preferred version 2.35 of glibc not available (for item libsegfault)

WARNING: versions of glibc available: 2.27 2.31+gitAUTOINC+1094741224

WARNING: preferred version 2.35 of nativesdk-glibc not available (for item nativesdk-libsegfault)

WARNING: versions of nativesdk-glibc available: 2.27 2.31+gitAUTOINC+1094741224


It seems that the unused/older recipe versions are still considered for dependencies somehow, just because they exist in the layer.

I understand that the old glibc versions provide libsegfault and that it can’t be found in the preferred version, but I really don’t care about the other versions as I have not selected them.

I could completely remove the packages from the old versions, but that seems like a brute force hack affecting what the recipes could provide when I select them.


Is there a clean way to modify/bbappend the recipes to best fix, or at least suppress such warnings when the recipe versions causing them are not selected?

Is there a way to do version based dependency declarations to be recipe version rather than recipe name specific?





Join { to automatically receive all group messages.