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

[Khem Raj]

On 2/26/20 12:21 PM, Böszörményi Zoltán wrote:
> 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.
> 

OK, I guess, we should give it a test.

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