[Pkg-fglrx-devel] Bug#695884: Bug#695884: Re[2]: Bug#695884: amd potentially improper OpenCL dependencies

[Vincent Danjean]

  Hi,

Le 25/01/2013 12:32, Patrick Matthäi a écrit :
> Am 24.01.2013 04:01, schrieb Bob Bib:
> 
>> OK, then we should also probably replace the change
>> made in experimental fglrx-driver/1:13.1-1
>> for "amd-clinfo" & "amd-libopencl1":
>> Recommends: amd-opencl-icd
>>   with following:
>> Recommends: amd-opencl-icd | opencl-icd
> 
> ACK, or are there any different opinions?

  I like the proposal of Andreas in #695883

Le 24/01/2013 11:14, Andreas Beckmann a écrit :
> Hi,
>
> while implicitly recommending amd-opencl-icd is not such a bad idea (it
> comes with a CPU implementation as well, so is usable for many people
> even without proprietary graphics cards), perhaps it's better not to
> Recommend a "random" icd by default and require explicit installation of
> the required icd.
>
> Package: ocl-icd-libopencl1
> Suggests: opencl-icd
> # require explicit installation of an icd

Once pocl (a free implementation of OpenCL) will be accepted in unstable
(package in collab-maint nearly ready to be uploaded to unstable),
ocl-icd-libopencl1 will recommends pocl-icd | opencl-icd

> Package: vendor-libopencl1:
> Recommends: vendor-opencl-icd, opencl-icd
> # user probably wants exactly this if he installs vendor driver
> # and switching loader vendors should not "orphan" foreign icds
>   (yes, comma, not pipe)

I do not see the interest of the comma. vendor-opencl-icd will
provides opencl-icd in the usual case. And if a user goes against
recommends for vendor-opencl-icd, he can do what ever he wants
for the second. So, what is the interest of the second one
(opencl-icd) ?

> Package: vendor-opencl-icd
> Depends: ocl-icd-libopencl1 | vendor-libopencl1 | libopencl1
> # yes, we want to get bug reports for ocl-icd loader working not
> # properly with vendor icd implementations
>
> or
>
> Package: vendor-opencl-icd
> Depends: vendor-libopencl1 | libopencl1
> # use the well-tested driver from first vendor to be installed
> # should avoid any possible interoperability problems
> # probably more multiarch conflicts
>   (install ocl-icd-libopencl1; install vendor-opencl-icd:foreign)

I prefer the first one as we try to promote more free software.

> For clinfo:
>
> Package: vendor-clinfo
> Suggests: opencl-icd
> # require explicit icd installation
>
> or
>
> Package: vendor-clinfo
> Depends: ocl-icd-libopencl1 | libopencl1
> Recommends: opencl-icd, vendor1-opencl-icd, vendor2-opencl-icd
> # recommend all to get a better out-of-the-box result

Unless I'm mistaken, only amd provides amd-clinfo. And this little
program is a plain OpenCL programs that can work with all OpenCL
implementations.

I would propose :
Package: amd-clinfo
Depends: ocl-icd-libopencl1 | libopencl1
Suggests: opencl-icd


> Maybe we should provide some more virtual packages in the -icd packages:
> opencl-icd-gpgpu // or is there a better term that covers
>                  // Nvidia GTX xyz, Nvidia Tesla, Radeon HD wxyz
> opencl-icd-gpgpu-$VENDOR
> opencl-icd-cpu
> opencl-icd-cpu-$CPUVENDOR

I'm not sure we will have really useful virtual package. I do not
have strong opinion on this part.

> Would it be useful to make clinfo M-A: same co-installable? Rename the
> binaries to clinfo-$ARCH or $ARCH-clinfo (fsvo ARCH, maybe better the
> multiarch triplet) and a clinfo wrapper script that runs the one for the
> primary arch (and thereafter for the secondary arches ?) Maybe amend the
> output a bit if there are more than one binary to be run, but keep the
> original output if there is only one.

Is there other examples of user (ie in PATH) binary programs that
are M-A: same co-installable? If we go this path, I think we must
talk with people more involved in M-A to be sure to use a correct
set of conventions.

  Regards,
    Vincent

> Andreas

-- 
Vincent Danjean          Adresse: Laboratoire d'Informatique de Grenoble
Téléphone:  +33 4 76 61 20 11            ENSIMAG - antenne de Montbonnot
Fax:        +33 4 76 61 20 99            ZIRST 51, avenue Jean Kuntzmann
Email: Vincent.Danjean at imag.fr           38330 Montbonnot Saint Martin