Re: [EXTERNAL] Re: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the default dependencies"

[Randolph Sapp <rs@ti.com>]

On 8/28/23 11:22, Randolph Sapp wrote:
> On 8/28/23 10:09, Max Krummenacher wrote:
>> On Mon, Aug 28, 2023 at 5:01 PM Max Krummenacher via
>> lists.openembedded.org <max.oss.09=gmail.com@lists.openembedded.org>
>> wrote:
>>>
>>> On Sun, Aug 27, 2023 at 11:23 PM Peter Kjellerstedt
>>> <peter.kjellerstedt@axis.com> wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Max Krummenacher <max.oss.09@gmail.com>
>>>>> Sent: den 27 augusti 2023 10:10
>>>>> To: openembedded-core@lists.openembedded.org; Peter Kjellerstedt
>>>>> <peter.kjellerstedt@axis.com>
>>>>> Cc: Max Krummenacher <max.krummenacher@toradex.com>; Randolph Sapp
>>>>> <rs@ti.com>
>>>>> Subject: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: 
>>>>> Inhibit the
>>>>> default dependencies"
>>>>>
>>>>> From: Max Krummenacher <max.krummenacher@toradex.com>
>>>>>
>>>>> Hi
>>>>>
>>>>> With commit d1d09bd4d7 ("bin_package.bbclass: Inhibit the default
>>>>> dependencies") applied I'm getting a lot of these errors, i.e. qa
>>>>> does miss libc and compiler provided libs:
>>>>>
>>>>> ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
>>>>> /usr/lib/libusc.so.23.1.6404501 contained in package 
>>>>> ti-img-rogue-umlibs
>>>>> requires ld-linux-aarch64.so.1(GLIBC_2.17)(64bit), but no providers 
>>>>> found
>>>>> in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
>>>>> ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
>>>>> /usr/lib/libusc.so.23.1.6404501 contained in package 
>>>>> ti-img-rogue-umlibs
>>>>> requires libc.so.6(GLIBC_2.17)(64bit), but no providers found in
>>>>> RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
>>>>> ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
>>>>> /usr/lib/libufwriter.so.23.1.6404501 contained in package 
>>>>> ti-img-rogue-
>>>>> umlibs requires libstdc++.so.6(GLIBCXX_3.4.14)(64bit), but no 
>>>>> providers
>>>>> found in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
>>>>>
>>>>> Reverting the commit makes the build pass, alternatively adding
>>>>> to depends in the recipe which is using the bin_package class
>>>>> fixes it too:
>>>>>
>>>>> DEPENDS += " virtual/${TARGET_PREFIX}compilerlibs virtual/libc"
>>>>>
>>>>> I'd prefer reverting removing the default dependencies over fixing
>>>>> each of the recipes which do use the bin_package class to actually
>>>>> install binaries running in the target user space.
>>>>>
>>>>> Any opinions?
>>>>
>>>> Bummer. I guess we will have to update our recipes individually
>>>> instead. :(
>>>
>>>  From the bugzilla entry [1] which added the feature and from the commit
>>> adding the class [2] it looks to me that the class should simplify 
>>> adding
>>> binaries externally built for the target.
>>> Having the users of the class having to add the used libc / compiler
>>> shared objects to not trigger a qa warning seems really wrong to me.
>>>
>>> Additionally I don't see the advantage in not installing the base
>>> dependencies. Doing anything usefull in a build would need to build
>>> them anyway for some other recipe, so one would save creating a few
>>> hard links. Do I miss something here?
>>>
>>> So IMHO a recipe which inherits the class and really does not like the
>>> default dependencies should add the `INHIBIT_DEFAULT_DEPS = "1"`.
>>
>> Adding the missing links, sorry about that:
>> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1592
>> [2] 
>> https://www.openembedded.org/pipermail/openembedded-core/2012-September/067782.html
> 
> Thanks for bringing this to light Max. I have no opinion in this. I 
> understand not wanting to implicitly depending on anything. After all, 
> explicit is always nice for those that don't want to navigate the full 
> include chain to figure out recipe dependencies. It's also nicer for a 
> minimal build (though arguably not in this case because these are core 
> packages we're depending on).
> 
> If this is going to be the standard moving forward please let me know so 
> I can update this recipe accordingly.

Scratch that, I have an opinion now. Removing hidden base package 
dependencies that QA steps explicitly rely is a bad idea. Please revert 
this.