[Pkg-opencl-devel] [RFC] multiarch and virtual packages

[Vincent Danjean]

Le 03/10/2013 13:04, David Kalnischkies a écrit :
> On Thu, Oct 3, 2013 at 11:54 AM, Vincent Danjean <vdanjean.ml at free.fr> wrote:
>>   I tried several variation, adding :same and/or :i386/:amd64 to
>> the Conflicts and/or Provides in ICD Loader. I do not succeed into
> 
> :same doesn't exist (in this context), where did you find that?

It was just random tests.

> Anyway, negative dependencies (Conflicts/Breaks/Replaces) effect all
> architectures and can't be limited to specific architectures currently [0].
> 
> [0] https://wiki.ubuntu.com/MultiarchSpec#Architecture-specific_Conflicts.2BAC8-Replaces

Thanks for the pointer to the official spec. I missed this paragraph.

>>   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).
> 
> How about alternatives instead of this Provides/Conflicts/Replaces stuff
> to allow multiple loaders per architecture (and such an alternative is
> architecture specific by design).

as for glx libraries in NVidia packages? It can be a solution yes
but I cannot imagine a reason for that for now. And alternatives can
become tricker when -dev packages (with the .so symlink) come into
play.

> And could the virtual package maybe named 'opencl-loader-api-1' or
> something?

Why ? The package providing a OpenCL ICD Loader must provide
a libopencl.so.1 shared library in the library search path. So
libopencl1 or libopencl-1 seem logical to me.

  Best regards,
    Vincent

> Best regards
> 
> David Kalnischkies
> 
> P.S.: If you wanna play, try APTs testcases. :)
> 
> 


-- 
Vincent Danjean          Adresse: Laboratoire LIG - Bât. INRIA Rhône-Alpes
Téléphone:  +33 4 76 61 55 10            655 avenue de l'Europe
Fax:        +33 4 76 61 52 52            Montbonnot Saint Martin
Email: Vincent.Danjean at imag.fr           38334 Saint-Ismier cedex