Re: [morty/master][PATCH 1/2] ocl: update to version 1.1.12.0

[Jacob Stiffler <j-stiffler@ti.com>]

On 3/17/2017 9:38 AM, Jacob Stiffler wrote:
>
>
> On 3/16/2017 4:28 PM, Denys Dmytriyenko wrote:
>> On Thu, Mar 16, 2017 at 03:23:59PM -0400, Denys Dmytriyenko wrote:
>>> On Thu, Mar 16, 2017 at 03:20:33PM -0400, Denys Dmytriyenko wrote:
>>>> Jake,
>>>>
>>>> It appears the new version no longer provides libOpenCL.so - is it 
>>>> expected?
>>> Actually, it does provide it, just messing up the debian package 
>>> renaming due
>>> to all the new stuff... I'll see if I can correct it.
>> It's not just few packagegroups, it's everything that depends on opencl
>> (opencv, openmp, examples, etc.) is affected. If you build from 
>> scratch every
>> time, you won't see it.
>>
>> I've submitted a patch to hopefully resolve it:
>> http://arago-project.org/pipermail/meta-arago/2017-March/008854.html
>>
>> This doesn't only affect incremental builds, but also package feeds 
>> and would
>> break package/distro upgrades in the field. Unfortunately, we haven't 
>> been
>> paying much attention to this problem in the past, but as we've already
>> discussed, we should keep an eye on it...
>>
> I'm trying to understand this automatic package naming, and how the 
> opencl package gets renamed to libopencl when the IPK is created. 
> Could you point to where this occurs in OE?
>

Reading the comment on your patch shows why this happens, and I have 
found that the code responsible is in the debian.bbclass.

> I also see that on krogoth, everything is OK. Even with the new 
> binaries, the IPKs are still name libopencl*. However, I do see that 
> on morty, the addition of the binaries does alter the IPK names.
>

I see the it was OK because your patch was already committed. Removing 
that patch shows the problem.

> I'll look at the patch and provide comments once I better understand 
> what is happening.
>

We may need to take a closer look at the packaging and dependencies. I 
would assume that the library RDEPENDS on the daemon, so it might not 
make sense to have opposite dependency in the packages (runtime RDEPENDS 
on libraries).

> - Jake