[Pkg-opencl-devel] adding more virtual packages libopencl-1.X-1 ?

[Andreas Beckmann]

On 2013-07-24 16:46, Vincent Danjean wrote:
> Le 24/07/2013 13:15, Andreas Beckmann a écrit :
>> Should we provide similar libopencl-X.Y-dev virtual packages as well?
> 
> Good question.
> 
> One difficulty is that current khronos headers can be used to compiled 1.0
> and 1.1 programs *iff* they define some preprocessor symbols such as
> CL_USE_DEPRECATED_OPENCL_1_1_APIS
> 
> The second difficulty is that libOpenCL.so is, for now, provided by the
> libopencl1 package (and not the -dev one). The reason is that the Intel
> OpenCL library does not have an soname. So, if we want to be able to
> run OpenCL programs compiled with the Intel compiler, we need to
> provide this libOpenCL.so

I'm fine with moving libOpenCL.so around a bit

> What about this proposal (I do not try to take into account the migration
> from the current state for now):
> 
> * "vendor"-libopencl1 runtime packages (providing libOpenCL.so.1)
>   + do not include libOpenCL.so anymore
>   + provides/conflicts/replaces the virtual libopencl1 package
>   + provides (if supported) libopencl-X.Y-1 virtual packages
>   + ensure that compiled programs depends on
>     libopencl1, libopencl-X.Y-1,
OK
> opencl-icd-X.Y (better name here ?)
not sure about that one

> * libopencl-intel-runtime-support (in contrib ?)
>   + provide the libOpenCL.so
>   + depends on ocl-icd-libopencl1 (to be sure to find the libOpenCL.so.1
>     in the good directory)
>   + must only be installed to run OpenCL programs compiled with the
>     Intel ICD Loader
OK

> * devel packages
>   + include the libOpenCL.so file
>   + conflicts/replaces/(provides ?) libopencl-intel-runtime-support
>   + depends on opencl-headers
>     or include OpenCL header files and conflicts/replaces opencl-headers
>   + provides opencl-dev (? This is currently done)
>   + provides (if supported) libopencl-X.Y-dev virtual packages
>     (do they provides  libopencl-1.1-dev if
>     CL_USE_DEPRECATED_OPENCL_1_1_APIS must be used ? I think yes but I'm
>     not sure)
>   + depends on a package providing libOpenCL.so.1
>     (they cannot depends on the virtual libopencl1 package because they
>     need to know the precise place of libOpenCL.so.1 for the libOpenCL.so
>     symlink)
OK
> * "vendor"-opencl-icd packages
>   + provides (if supported) opencl-icd-X.Y virtual packages
problematic, as old icds should work with newer libs
> * OpenCL applications
>   + depends, through the symbol files of libOpenCL.so.1, to
>     ° libopencl1 (ie a ICD loader)
>     ° one or more libopencl-X.Y-1 (to ensure that the installed ICD loader
>       supports the used ABI)
ACK
>     ° one or more opencl-icd-X.Y (to ensure that a compatible ICD is installed)
I think we should postpone the icd compatibility issue and stay with
opencl-icd for now
> 
> And, suddenly, I think that all of this must be re-thinked with
> multiarch in mind... I will do it later.

multiarch support seems to work as it is now, so we probably won't have
to change anything here

vendor1-libopencl1:i386 and vendor1-libopencl1:amd64 are coinstallable
vendor1-libopencl1:i386 and vendor2-libopencl1:amd64 aren't

>From a transition oiunt of view that should be easy as everything that
is currently in the archive will continue to work (more ore less as it
is now), getting them binNMUed will tighten the dependecies.


Andreas