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

[Andreas Beckmann]

Hi,

we should somehow get back to this topic ... I've implemented the new
approach with libopencl-1.X-1 in the nvidia packages in unstable (and
experimental) and the fglrx packages in experimental. So far I didn't do
anything about the ICDs nor did I do extensive tests with the new
virtual packages.


Andreas

On 2013-07-26 12:02, Andreas Beckmann wrote:
> 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
> 
> _______________________________________________
> Pkg-opencl-devel mailing list
> Pkg-opencl-devel at lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-opencl-devel
>