[OE-core] [PATCH 2/5] libva-initial: New recipe to carry only pkgconfig files and headers

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

2020. 02. 26. 20:44 keltezéssel, Khem Raj írta:
> 
> 
> On 2/26/20 9:14 AM, Böszörményi Zoltán wrote:
>> 2020. 02. 26. 18:08 keltezéssel, Böszörményi Zoltán írta:
>>> 2020. 02. 26. 17:51 keltezéssel, Khem Raj írta:
>>>>
>>>>
>>>> On 2/26/20 7:58 AM, Böszörményi Zoltán wrote:
>>>>> 2020. 02. 26. 16:30 keltezéssel, Khem Raj írta:
>>>>>> On Wed, Feb 26, 2020 at 7:20 AM Böszörményi Zoltán <zboszor at pr.hu> wrote:
>>>>>>>
>>>>>>> 2020. 02. 26. 16:13 keltezéssel, Khem Raj írta:
>>>>>>>> On Wed, Feb 26, 2020 at 7:12 AM Böszörményi Zoltán <zboszor at pr.hu>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> 2020. 02. 26. 15:58 keltezéssel, Khem Raj írta:
>>>>>>>>>> On Wed, Feb 26, 2020 at 6:05 AM Böszörményi Zoltán via
>>>>>>>>>> Openembedded-core <openembedded-core at lists.openembedded.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> The package name exploits sstate.bbclass so it's not added as
>>>>>>>>>>> implicit dependency to packages.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> what is the use of this recipe and why should it be added to core ?
>>>>>>>>>
>>>>>>>>> I should have added a cover letter, shouldn't I?
>>>>>>>>> See patch 3/5 in the series for enabling gallium-va in Mesa.
>>>>>>>>>
>>>>>>>>
>>>>>>>> recipe seems to build full libva, so why not just use that instead.
>>>>>>>
>>>>>>> You don't seem to be reading mails from openembedded-devel that
>>>>>>> you were cc-ed on.
>>>>>>
>>>>>> don't assume things
>>>>>
>>>>> Understood.
>>>>>
>>>>>>> http://lists.openembedded.org/pipermail/openembedded-devel/2020-February/205142.html
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I am trying to make us thing if -dev package can be used somehow to
>>>>>> avoid this
>>>>>> or have we exhausted all possibilities.
>>>>>
>>>>> Why is it a problem to exploit sstate.bbclass internals implicitly
>>>>> by using a *-initial package name for an arbitrary package?
>>>>
>>>> it is not a problem, however, it is a work to keep such setup going and
>>>> also it has to be considered always in dependencies etc.
>>>>
>>>>> Surely it's not reserved for libgcc-initial and friends.
>>>>>
>>>>
>>>> they are different usecases, libgcc-initial is a veneer/trampoline used
>>>> to bootstrap toolchain, and that too we want to remove at every
>>>> opportunity we get, we use to have lot of initial recipes and they are
>>>> very few left, so we have to be mindful of adding another one.
>>>>
>>>>> It solves two problems nicely in one go:
>>>>> 1. by using a different package than libva, the libva-vs-mesa
>>>>>     circular dependency is avoided. mesa needs a crippled libva
>>>>> (pkgconfig + headers)
>>>>>     to build its VAAPI state tracker and the VAAPI drivers
>>>>
>>>> I see archlinux using full libva for this. how are other distros doing
>>>> it? is this problem unique to OE
>>>
>>> Fedora also uses the full libva.
>>>
>>> However, the chicken-and-egg circular dependency is broken by history
>>> for these distros.
>>>
>>> Koji and Mock build one package at a time with all their dependencies
>>> already available from the staging package repository and the results
>>> will be eventually uploaded to the same repository.
>>>
>>> Bitbake doesn't have have this loophole to download pre-built dependencies.
>>
>> Also, somewhere on 01.org or in the libva sources the same solution
>> I presented in this patchset is suggested:
>>
>> 1. build libva with --disable-glx (it is needed when Mesa SDK is present)
>>     but it's not needed by not depending on mesa in libva-initial
>> 2. build mesa with libva build in (1) as it only needs the pkgconfig files
>>     and the headers
>> 3. build libva with --enable-glx. It's autodetected, set to on with
>>     depending on mesa in the full libva recipe.
> 
> looking at the nature of the problem, it might be the way to unbreak the catch-22, does 
> anything else needs this bootstrap header package ?

Besides DEPENDS="libdrm", no.

> do we need to ensure that content of libva-dev and the bootstrap packages do not overlap.

I don't think so.
Apparently, the mesa-dev package built from this patchset
doesn't depend on libva-initial-dev and this latter package
doesn't get included into an image either. I guess the
sstate.bbclass internals deal with this properly.


> 
>>
>> Obviusly the same libva recipe can't be used to build mesa that depends on mesa.
>>
> 
>