On Tue, Feb 18, 2014 at 15:55:49 +0100, Vincent Danjean wrote: > On 18/02/2014 14:17, Julien Cristau wrote: > > On Tue, Feb 18, 2014 at 13:34:47 +0100, Vincent Danjean wrote: > > > >> So, do you think we can close this bug? Else, what is your > >> precise problem? > >> > > As far as I can tell from the few packages I looked at with wrong > > dependencies, it appears they were built with ocl-icd 1.3-3. The > > current symbols file does appear to be reasonable (I'm not completely > > sure about the presence of #MINVER# together with virtual packages, but > > that's rather minor compared to the previous state of generating purely > > virtual dependencies). > > It has no influence as ocl-icd-libopencl1 provides the alternative > virtual package. So, it is purely cosmetic. I can remove it if you > think it is better (note that #MINVER# applies to the real package > #PACKAGE# (ie ocl-icd-libopencl1), not to the libopencl1 virtual > package). > > > I guess we'll just have to rebuild the rdeps to > > get rid of the wrong libopencl1 deps. > > The bug with old ocl-icd, as consequence, only forbid installation > of non-free libopencl (only ocl-icd-libopencl1 can be installed to > satisfy the generated dependencies). That's why I did not yet ask > for rebuild of reverse dependencies. "Normal" upload of OpenCL > program should fix this quickly enough. > We must be talking about a different bug, because the consequence of the current dependencies on plain 'libopencl1' in clinfo or erlang-cl is that a random provider gets installed.
Cheers, Julien
signature.asc
Description: Digital signature
