severity 739409 normal
thanks
Hi,
On 04/04/2014 21:21, Andreas Cadhalpun wrote:
> Control: severity -1 serious
> Justification: breaks other packages
You are kidding? The only effect of this bug is that, if you enable
the non-free Debian repo, then a non-free package can sometimes be
installed by default where another free one (from main) would work.
If installing another ICD Loader really does not work, then this
is another bug that has nothing to do with depends. ICD Loaders are
meant to be exchangeable.
I'm downgrading the severity of this bug.
> Hi Vincent,
>
> the current symbols file is still broken. It contains:
> 1: libOpenCL.so.1 #PACKAGE# #MINVER# | libopencl1
> 2: | #PACKAGE# #MINVER# | libopencl1, libopencl-1.1-1
> 3: | #PACKAGE# #MINVER# | libopencl1, libopencl-1.2-1
> 4: (symver|optional)OPENCL_1.0 1.0 1
> 5: (symver|optional)OPENCL_1.1 1.0 1
> 6: (symver|optional)OPENCL_1.2 1.0 2
>
> The problems are in line 2 and 3, as the virtual packages libopencl-1.1-{1,2}
> are added without real package providing this interface.
I was hopping that the first alternative would be a good enough
hint for package managers. It seems not. I will apply your patch.
> This creates the following dependencies (from python-pyopencl):
> Depends: libopencl-1.1-1, libopencl-1.2-1, ocl-icd-libopencl1 (>= 1.0) |
> libopencl1, opencl-icd
> Now if you try to install this package, apt satisfies the libopencl-1.1-1
> dependency randomly, for me by installing nvidia-libopencl1. (A similar
> problem is the opencl-icd dependency, but that is added by pyopencl itself.)
nvidia-libopencl1 does not provide libopencl-1.2-1 and conflict
with libopencl1. So I find this fact very suspicious. Do you have
any evidence of it? What are the precise versions of all involved
packages (in particular nvidia-libopencl1).
But I agree that amd-libopencl1 can be installed if the package
manager try to satisfy "libopencl-1.2-1" before
"ocl-icd-libopencl1 (>= 1.0) | libopencl1" (that said, it needs you
to have enable the non-free Debian repo *and* it should indeed work)
Note that opencl-icd is a different problem. It tells that your
program needs a ICD (ie OpenCL implementation). However, to my
knowledge (and same for other involved maintainers), there is no
way to express in dpkg/apt a depends on a ICD that will work for
your current hardware. So, this force you to install an ICD but
you will need to select a correct one for your machine.
> Attached is a patch that fixes this problem in ocl-icd.
>
> Additionally, I'm not sure if you are aware of [1]:
> "Packages MUST NOT use virtual package names (except privately, amongst
> a cooperating group of packages) unless they have been agreed upon and
> appear in this list."
>
> I think it would be a good idea to add the libopencl* virtual packages
> to that list, because they can be added automatically via the symbols
> file, which is not exactly using 'privately, amongst
> a cooperating group of packages'.
However, that the case. They are used privately amongst OpenCL related
packages. There have been discussions explaining the reasons.
No maintainer of external packages should add them manually.
No package unrelated with OpenCL should use them at all.
> But before you attempt this, I think you should coordinate with the
> other packages currently providing these libraries and standardize
> the symbol names.
This is not possible unless you are able to modify the binaries
provided by AMD, NVidia (and even Intel that, in its libopencl1.so
library doe no even use the correct SONAME...)
In any case, this is out the scope of the power of Debian Developer
(AMD and NVidia are in non-free, not in main, Intel ones is not
even in non-free due to an error in there licencing file. They promise
me to correct this on a forum but I did not see any fact until now...)
> ocl-icd-libopencl1 uses @OPENCL_*, while e.g. nvidia-libopencl1 uses
> @BASE, so if a program is compiled with ocl-icd-opencl-dev and used
> with nvidia-libopencl1 (which apt installs by default with the current
> broken symbols file), it will produce errors like:
> undefined reference to `clReleaseMemObject@OPENCL_1.0'
Are you sure? When I test it a few months (years) ago, there was
only a warning. Look at line 310 and following at
http://anonscm.debian.org/gitweb/?p=collab-maint/ocl-icd.git;a=blob;f=debian/README.Debian;hb=HEAD
Perhaps the linker behavior changed since this time.
> This happens in my use case:
> I packaged FFmpeg for Debian [2]. Adding opencl support breaks the
> compilation of many possible reverse dependencies due to this problem.
I do not really understand what you mean. If the linker did not change
its behavior, then the chosen solution (versioned symbols) allowed
all possible runtimes (sometimes at the expense of a warning).
Note that, if the linker changed its behavior, as AMD and NVidia
does not use the same thing (AMD also use versioned symbols), then
we wont be able to keep binary compatibility with all these ICD loaders.
In this case, ocl-icd will still keep its versioned symbols but I
will need to talk with NVidia maintainer so that we stop using the
same virtual packages (that were here to denote a binary compatibility).
Regards,
Vincent
> Best regards,
> Andreas
>
>
> 1: https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
> 2: http://bugs.debian.org/729203
--
Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
