On Wed, Jun 27, 2012 at 13:32:53 +0200, Vincent Danjean wrote: > severity 679228 normal > thanks > > Hi, > > Le 27/06/2012 12:16, Ansgar Burchardt a écrit : > > Package: ocl-icd-libopencl1 > > Version: 1.1-1 > > Severity: serious > > > > ocl-icd-libopencl1 ships the unversioned .so in the library runtime > > package, however Policy 8.2 says > > > > ---- > > If your package contains files whose names do not change with each > > change in the library shared object version, you must not put them in > > the shared library package. Otherwise, several versions of the shared > > library cannot be installed at the same time without filename clashes, > > making upgrades and transitions unnecessarily difficult. > > ---- > > Our libopencl1 shared library has a proper SONAME (libopencl.so.1). > Note that, as this is a free implementation of a library implemented > by several vendors, we *need* to keep in sync with them if we want > to keep binary compatibility. I plan to diffuse on d-d a document > about the situation of OpenCL in Debian. I will try to think to cc > this bug.
That would imply that binary compatibility exists in the first place. Is there an ABI spec for libopencl.so? If yes it must include a proper version. > In this case, the .so symlink is kept in the library package (instead > of putting it in the dev package) because Intel version of the library > use the "libopencl.so" soname instead of "libopencl.so.1". > We plan to solve this issue with Intel in order to keep binary > compatibility but this is not done yet. Sounds to me like we shouldn't ship this until that is fixed. > Note that amd-libopencl1 and nvidia-libopencl1 packages do the > same thing. > Just because others are doing it wrong, ... Cheers, Julien
signature.asc
Description: Digital signature
