[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[RFC] multiarch and virtual packages


  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

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
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?


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         vdanjean@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

Reply to: