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

[Denys Dmytriyenko <denys@ti.com>]

On Fri, Mar 17, 2017 at 10:46:35AM -0400, Jacob Stiffler wrote:
> 
> 
> 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.

Sorry, couldn't wait any longer - had to make 2016.06.01 RC build last 
night...


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

First of all, I noticed that ${PN}-runtime wasn't even used - it had no 
FILES_${PN}-runtime defined, thus not packaging any files. What was it's 
intentional purpose?
If needed, we can change the way files get packaged and dependencies between 
them.

Second, it's unfortunate that this package renaming slipped through unnoticed 
in the very beginning for opencl - not sure if it was meant to be just a 
library or not. If the main purpose of opencl package is indeed to provide 
libOpenCL.so library, then it's fine for the package to stay as libopencl1*. 
Otherwise we could have disabled automatic debian renaming for it...

-- 
Denys