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

["Böszörményi Zoltán" <zboszor@pr.hu>]

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.

> 
>> 2. by using libva-initial as the package name, the per-recipe sysroot issue
>>     is avoided where prepare-sysroot for a 3rd package like
>> intel-vaapi-driver
>>     would fail because the real libva the crippled variant would install
>>     identical files
>>
> 
> right, this is the problem I am afraid of creating almost duplicate packages
> 
>>>
>>>>>
>>>>>>>
>>>>>>>> Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
>>>>>>>> ---
>>>>>>>>      meta/recipes-graphics/libva/libva-2.6.1.inc        | 4 +++-
>>>>>>>>      meta/recipes-graphics/libva/libva-initial_2.6.1.bb | 5 +++++
>>>>>>>>      2 files changed, 8 insertions(+), 1 deletion(-)
>>>>>>>>      create mode 100644
>>>>>>>> meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>>>>
>>>>>>>> diff --git a/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>>>> b/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>>>> index ca1386d80b..5b1cdee7e3 100644
>>>>>>>> --- a/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>>>> +++ b/meta/recipes-graphics/libva/libva-2.6.1.inc
>>>>>>>> @@ -17,10 +17,12 @@ SECTION = "x11"
>>>>>>>>      LICENSE = "MIT"
>>>>>>>>      LIC_FILES_CHKSUM =
>>>>>>>> "file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
>>>>>>>>
>>>>>>>> -SRC_URI =
>>>>>>>> "https://github.com/intel/${BPN}/releases/download/${PV}/${BP}.tar.bz2"
>>>>>>>>
>>>>>>>> +SRC_URI =
>>>>>>>> "https://github.com/intel/libva/releases/download/${PV}/libva-${PV}.tar.bz2"
>>>>>>>>
>>>>>>>>      SRC_URI[md5sum] = "aef13eb48e01a47d1416d97462a22a11"
>>>>>>>>      SRC_URI[sha256sum] =
>>>>>>>> "6c57eb642d828af2411aa38f55dc10111e8c98976dbab8fd62e48629401eaea5"
>>>>>>>>
>>>>>>>> +S = "${WORKDIR}/libva-${PV}"
>>>>>>>> +
>>>>>>>>      UPSTREAM_CHECK_URI = "https://github.com/intel/libva/releases"
>>>>>>>>
>>>>>>>>      DEPENDS = "libdrm"
>>>>>>>> diff --git a/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>>>> b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>>>> new file mode 100644
>>>>>>>> index 0000000000..828ef6fbca
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/meta/recipes-graphics/libva/libva-initial_2.6.1.bb
>>>>>>>> @@ -0,0 +1,5 @@
>>>>>>>> +require libva-${PV}.inc
>>>>>>>> +
>>>>>>>> +do_install_append () {
>>>>>>>> +       rm -f ${D}${libdir}/*.so*
>>>>>>>> +}
>>>>>>>> -- 
>>>>>>>> 2.24.1
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> _______________________________________________
>>>>>>>> Openembedded-core mailing list
>>>>>>>> Openembedded-core@lists.openembedded.org
>>>>>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>>>>
>>>>
>>