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

[Khem Raj <raj.khem@gmail.com>]

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@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@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@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 ?
do we need to ensure that content of libva-dev and the bootstrap 
packages do not overlap.

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