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

[Steve Langasek]

On Thu, Oct 03, 2013 at 01:04:09PM +0200, David Kalnischkies wrote:
> 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?
> 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

Yes, mostly because at the time this was being discussed we couldn't figure
out a way to express architecture-specific vs. all-architecture
Conflicts/Provides sensibly, so we went with the conservative option that
would avoid packages declaring conflicts that would not actually be honored.

But there are certainly real use cases for having Provides: be treated as
architecture-dependent, and avoid cross-conflicting with them.  As a perfect
example of this, see libjack-jackd2-0 vs. libjack0, which both
Provide/Replaces/Conflicts libjack-0.116.  Why should the user have to have
the same implementor of this virtual package on all architectures, which is
what's currently required?  Or libc-dev: on some architectures, this is
provided by libc6-dev, but other architectures have different names for the
-dev package, which makes cross-building for these architectures using
multiarch quite impossible.

So I think these are use cases that we want to be able to support, but the
counterpoint is that if two packages declare a conflicts due to files that
are not in architecture-qualified paths, we don't want apt to ignore this.
E.g., libfoo4-dev and libfoo5-dev are both Multi-Arch: same, and each ship
their own copies of /usr/include/foo.h.  libfoo4-dev:i386 and
libfoo4-dev:amd64 are therefore coinstallable, but libfoo4-dev:i386
has a file conflict with libfoo5-dev:amd64 since their foo.h are not
identical.

Supporting both cases therefore requires some a further extension to the
syntax of either Conflicts or Provides.  Maybe we want to allow Conflicts:
<virtual_package>:same?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-opencl-devel/attachments/20131006/18b7fc5d/attachment.sig>