[oe] Trying to resolve build-time cyclic dependency between packages

[Böszörményi Zoltán]

2020. 02. 26. 9:49 keltezéssel, Böszörményi Zoltán via Openembedded-devel írta:
> Hi,
> 
> I am reviving this old idea with Zeus.
> 
> I have implemented the idea in an ALMOST satisfactory way, tested with
> Mesa 20.0.0.
> 
> Side note: Mesa 19.3 and 20.0 needs TOOLCHAIN="gcc" in Zeus,
> otherwise linker errors occur. See:
> https://gitlab.freedesktop.org/mesa/mesa/issues/2533
> 
> Mesa doesn't link to libva even with meson -Dgallium-va=true. It only
> needs the libva.pc pkgconfig file and the headers from libva to build
> its VA state tracker so the circular dependency is not that hard to solve.
> 
> I have this new recipe called libva-headers now that is a fork of the
> libva recipe and just deletes the libraries in do_install_append.
> 
> My Mesa recipe addendum has this line plus PACKAGECONFIG has "va":
> 
> PACKAGECONFIG[va] = "-Dgallium-va=true,-Dgallium-va=false,libva-headers"
> 
> Now, building libva is happy without the warning about libva.so is
> shipped by libva-headers (or libva-noglx in the previous incarnation)
> but now marked as shipped by libva because it was built later.
> 
> There is another problem now: anything that uses libva as dependency,
> like intel-vaapi-driver, implicitly pulls in mesa and then libva-headers
> so there is a clash in prepare-sysroot between libva and libva-headers
> because they still ship identical headers and pkgconfig files.
> 
> My current solution to the problem is to patch staging.bbclass to
> handle a new variable called EXCLUDE_DEPS but a line like this below
> needs to be added to all recipes that depends on libva, so it is
> quite intrusive for now.
> 
> EXCLUDE_DEPS = "libva-headers"
> 
> I am looking into storing data in "sstate", so libva-headers would add
> itself into a new class of packages that are not added to recipe-sysroot
> unless it is in DEPENDS explicitly.
> 
> My question is: is there a generic framework to do this already?

Talking to myself... YES THERE IS.
I just had to name the extra package as "libva-initial" and it works
the way I expected with no extra fuss.

> 
> This would allow me to not modify other recipes and may alsoserve other
> recipes with circular dependencies.
> 
> The end goal is to allow Chromium to be built with use_vaapi=true now that
> meta-browser has version 79 that includes the VAAPI patches. The current
> solution with setting EXCLUDE_DEPS already does this but as I said, it's
> not clean enough.
> 
> Best regards,
> Zoltán Böszörményi
> 
> 2015. 08. 09. 0:14 keltezéssel, Khem Raj írta:
>>
>>> On Jul 29, 2015, at 6:26 AM, Boszormenyi Zoltan <zboszor at pr.hu> wrote:
>>>
>>> Hi,
>>>
>>> I have a customized Mesa 10.6.3 package recipe which depends on libva
>>> to be able to build its mesa-va-driver subpackage, but libva also depends
>>> on Mesa to support GLX.
>>>
>>> Previously, I simply created a libva-noglx package that builds libva
>>> with --disable-glx that Mesa depend on and the "real" libva package can
>>> depend on Mesa.
>>>
>>> But since I also have to produce an SDK image with all the *-dev packages,
>>> creating such an initial image with bitbake fails because of a conflict
>>> in the dependency chain: libva-dev -> mesa-dev -> libva-noglx-dev.
>>>
>>
>> since libva-noglx is sort of a bootstrap package, you could empty/delete out the content
>> its puts into -dev packages and conflict will be gone. Other option is that you share
>> the content of -dev package in exclusive manner between libva and libva-noglx such
>> that they don’t package duplicate files
>>
>>> I have come up with the attached bbclass (based on Yocto 1.6) that
>>> now Mesa can inherit and that patches the RDEPENDS / RRECOMMENDS
>>> variables according to externally set variables. The comment at
>>> the beginning of the file explains how to use it.
>>>
>>> This pushes the cyclic dependency to opkg which happily breaks it and
>>> installs both libva* and *mesa* packages properly. Creating the initial
>>> image via bitbake works now.
>>>
>>> Comments?
>>>
>>> Best regards,
>>> Zoltán Böszörményi
>>>
>>> <cyclic-deps.bbclass>--
>>> _______________________________________________
>>> Openembedded-devel mailing list
>>> Openembedded-devel at lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>>
>>
>