Hi,
While trying to setup a correct description of dependencies for OpenCL
eco-system, we got a problem related to multi-arch. I will try to describe
here a simplified version of the situation to illustrate our main problem
(ie I do not take into account the various versions of OpenCL that can
coexists in the following text and I do not talk about -dev packages).
When talking about OpenCL, there are several components to consider:
- the ICD Loader: it is a library with a fixed name (libopencl.so.1) and
a defined ABI (list of function names more exactly) with several
existing implementations (AMD and NVidia ones are packaged
in non-free, ocl-icd provides one in main, Intel one is not packaged)
Any ICD Loader can be used for any OpenCL program and OpenCL
implementation. The ICD Loader only dispatches calls to various ICD.
- ICD: these are real OpenCL implementations. For now, only non-free
ones (AMD and NVidia) are packaged. They are used through the
ICD Loader. Several of them can be installed at the same time and even
used together in the same program. They are ELF libraries loaded from
the ICD Loader (with dlopen) whose name is stored into configuration
files in /etc/OpenCL/vendors/* .
- OpenCL applications (or language bindings) : they link to libopencl.so.1
and only use the defined ABI.
The current proposal about Depends/Conflicts/Provides is the following:
ICD Loader:
===========
Section: libs
Multi-Arch: same
Architecture: any
Provides: libopencl1
Conflicts: libopencl1
Replaces: libopencl1
Suggests (or Recommends): opencl-icd
ICD:
====
Section: libs
Multi-Arch: same
Architecture: any
Provides: opencl-icd
Enhances: libopencl1
OpenCL application:
===================
Architecture: any
Depends: libopencl1, opencl-icd
With this setup, nearly all works correctly. Installing a application:i386
will require a ICD Loader:i386 (a ICD Loader:amd64 that also provides
libopencl1 wont be accepted by dpkg. Good.)
The only "problem" is that it is not currently possible to install
an ICD Loader:i386 from one vendor and an ICD Loader:amd64 from another
vendor.
In ICD Loader, the "Conflicts: libopencl1" does not take into account
the architecture.
I tried several variation, adding :same and/or :i386/:amd64 to
the Conflicts and/or Provides in ICD Loader. I do not succeed into
getting the desired behavior (only one ICD Loader per architecture, but
no relation between ICD Loader for different architectures in multiarch).
I see (not tested) one solution: to use one virtual package per
architecture (libopencl1-i386, libopencl1-amd64, ...) but this means to
generate the Provides/Conflicts/Replaces field at build time (using
subst vars).
Is this the way to go in the multiarch world?
Is there something I missed wrt Provides/Conflicts and multiarch?
Regards,
Vincent
PS: if you want to play and to experiment dependencies on multiarch,
you can use my toy package on my home on alioth:
git clone ssh://git.debian.org/srv/home/users/vdanjean/public_git/ocl-test.git
As packages are empty, you can generate amd64 and i386 packages on the
same machine:
dpkg-buildpackage -us -uc -ai386 && dpkg-buildpackage -us -uc -aamd64
--
Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
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-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/524d3eef.7090...@free.fr
