Re: Fixing package dependencies across recipe versions?

Khem Raj

On Tue, Nov 22, 2022 at 11:29 PM Heinz Wrobel <Heinz.Wrobel@...> wrote:


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.
This is true and it happens because they all provide something
commonly, perhaps virtual/libc or somesuch. However, each one of them
does not replace exact providers
so they must match for one to overrride other. So you might consider
adding addtional needed PROVIDES in respective version of recipe via
bbappends or maybe main recipe itself.

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?
glibc is runtime dependency so you can only have one copy systemwide.
so having multiple recipes is only beneficial if you are building
different distributions from same workspace with different version of



Join { to automatically receive all group messages.