* lumin <cdlumin...@gmail.com>, 2015-09-03, 07:10:
http://mentors.debian.net/debian/pool/contrib/c/caffe/caffe_0.9999~rc2+git20150902+e8e660d3-1.dsc
Source caffe are built twice against different configurations, and are
compiled into 2 groups of binary packages, 4 in each group:
caffe-cpu conflict with caffe-cuda
libcaffe-cpu0 conflict with libcaffe-cuda0
libcaffe-cpu-dev conflict with libcaffe-cuda-dev
python-caffe-cpu conflict with python-caffe-cuda
Conflicting shared library packages? Sounds very suspicious...
We can see that:
* there is no problem at dependency of libcaffe-cpu0 and libcaffe-cuda0
* libdev packages have correct and healthy dependency.
* caffe-cpu depends on libcaffe-cpu0 (correct), and libcaffe-cuda0
(wrong), so does caffe-cuda
* python packages depends on both libcaffe-cpu0 and libcaffe-cuda0
However caffe-cpu and caffe-cuda suites are conflicting with each
other, which means the dependency entry generated by `dpkg-shlibdeps`
is wrong.
I looked up dpkg-shlibdeps(1), but found no option like 'exclude'
'prevent' etc...
My guess is that what you need is the -L option for dh_shlibdeps:
| -Lpackage, --libpackage=package
| With recent versions of dpkg‐shlibdeps, this option is generally not
| needed, unless your package builds multiple flavors of the same
| library.
|
| It tells dpkg‐shlibdeps (via its -S parameter) to look first in the
| package build directory for the specified package, when searching
| for libraries, symbol files,
| and shlibs files.
--
Jakub Wilk
