overzealous packagedata

overzealous packagedata

[Trevor Woerner]

I'm trying to build a certain combination of software for a given SoC. mesa
(meta-gl, specifically) provides a libgbm, but if you don't want to use mesa's
libgbm you can disable it with a PACKAGECONFIG. I.e.

	PACKAGECONFIG_remove_pn-mesa-gl = "gbm"

It works, and looking at the packages-split I can verify that nothing gets
installed for either mesa's libgbm nor libgbm-dev.

This particular SoC's BSP, however, provides an SoC-specific libgbm that
should be used in place of mesa's. This is easy, set the PREFERRED_PROVIDER,
tell mesa you don't want its gbm and everything is good, right?

:-(

The build fails because the *packagedata* from both mesa-gl and this SoC's
specific libgbm collide. The packagedata, I guess, states what *might* be
installed. So since both packages might install /usr/lib/libgbm, the build
freaks out:

	ERROR: mesa-gl-2_17.0.2-r0 do_packagedata_setscene: The recipe mesa-gl is trying to install files into a shared area when those files already exist. Those files and their manifest location are:
	  /z/build-master/bbb/build/tmp-glibc/pkgdata/beaglebone/runtime/libgbm-dev
	    (matched in manifest-beaglebone-libgbm.packagedata)
	  /z/build-master/bbb/build/tmp-glibc/pkgdata/beaglebone/runtime/libgbm
	    (matched in manifest-beaglebone-libgbm.packagedata)
	Please verify which recipe should provide the above files.

This is very annoying because, even if hell froze over and somehow both libgbm
and mesa-gl installed both of their libgbm packages, there would actually only
be one provider since mesa-gl's libgbm package is, in fact, empty.

Is there a way to get this to work? I can't not build mesa-gl, because I need
some of its parts (virtual/mesa, virtual/libgl) and I can't not use the SoC's
libgbm because (I'm guessing) that's what I'm supposed to use.

Re: overzealous packagedata

[Trevor Woerner]

...or let me ask this question another way...

Does anyone have accelerated graphics working on the beagleboard with x11
(ti-sgx-ddk-um?) and if so, what did you do to get it to build (and run)?

Re: overzealous packagedata

[Khem Raj]

On Thu, Apr 20, 2017 at 12:26 AM, Trevor Woerner <twoerner@gmail.com> wrote:
> I'm trying to build a certain combination of software for a given SoC. mesa
> (meta-gl, specifically) provides a libgbm, but if you don't want to use mesa's
> libgbm you can disable it with a PACKAGECONFIG. I.e.
>
>         PACKAGECONFIG_remove_pn-mesa-gl = "gbm"
>
> It works, and looking at the packages-split I can verify that nothing gets
> installed for either mesa's libgbm nor libgbm-dev.
>
> This particular SoC's BSP, however, provides an SoC-specific libgbm that
> should be used in place of mesa's. This is easy, set the PREFERRED_PROVIDER,
> tell mesa you don't want its gbm and everything is good, right?
>
> :-(
>
> The build fails because the *packagedata* from both mesa-gl and this SoC's
> specific libgbm collide. The packagedata, I guess, states what *might* be
> installed. So since both packages might install /usr/lib/libgbm, the build
> freaks out:
>
>         ERROR: mesa-gl-2_17.0.2-r0 do_packagedata_setscene: The recipe mesa-gl is trying to install files into a shared area when those files already exist. Those files and their manifest location are:
>           /z/build-master/bbb/build/tmp-glibc/pkgdata/beaglebone/runtime/libgbm-dev
>             (matched in manifest-beaglebone-libgbm.packagedata)
>           /z/build-master/bbb/build/tmp-glibc/pkgdata/beaglebone/runtime/libgbm
>             (matched in manifest-beaglebone-libgbm.packagedata)
>         Please verify which recipe should provide the above files.
>

mesa-gl is a separate recipe, if its providing more than gbm and that
extra stuff is needed too in your package thats when you might run
into these kind of issues. I would suggest to divide mesa-gl further
into more granular recipes.


> This is very annoying because, even if hell froze over and somehow both libgbm
> and mesa-gl installed both of their libgbm packages, there would actually only
> be one provider since mesa-gl's libgbm package is, in fact, empty.
>
> Is there a way to get this to work? I can't not build mesa-gl, because I need
> some of its parts (virtual/mesa, virtual/libgl) and I can't not use the SoC's
> libgbm because (I'm guessing) that's what I'm supposed to use.
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto