[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. 21:31 keltezéssel, Khem Raj írta:
> 
> 
> 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.

Sorry, I misread the question, it was too late after a workday.
Nothing else uses this bootstrap package just Mesa.

>>
>>> 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.
>>>>
>>>
>>>
>>