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@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@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature