On Thu, Jan 09, 2014 at 07:20:40PM +0000, Colin Watson wrote: > If you weren't one of the people in the "thinking extremely hard about > multiarch" BOF at DebConf, note that Multi-Arch: foreign denotes a point > in the dependency graph where you're allowed to switch architectures, > Multi-Arch: allowed denotes such a point if and only if the incoming > dependency is annotated with :any, and otherwise you may not switch > architectures; this holds even when you're going through an > Architecture: all package, so you're allowed to do this:
While thinking of Arch:all packages as being somewhat "transparent" and something to go through is convenient, this way of thinking risks to bring in the wrong associations. From a dpkg point of view, there is a special architecture (called native architecture, it happens to be the architecture of the dpkg package). Now Arch:all is just an alias for native. So the situation you pictured > Package: a > Architecture: i386 > Depends: b > > Package: b > Architecture: all > Depends: c > > Package: c > Architecture: i386 may actually be disallowed if you happen to use dpkg:amd64. This elaboration does not change any of your arguments, but I figured I'd pick on it again, because I have seen it gotten wrong so many times to the point of wanting to change this particular behaviour. ;-) > Bearing that in mind, let's go back to Kurt's options in > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682045#22, elaborated a > bit: Excuse my ignorance to previous discussion, but why is there no /usr/bin/<triplet>-libtool? To me it appears that libtools is similar in nature to a compiler in that it is executed on one architecture (build architecture in autoconf terms) and produces material useful on a (possibly) different architecture (host architecture). It is an established practise to prefix such tools with their host architecture. I recognize that libtool itself is a shell script that decides on most of the architecture specific stuff at runtime. But this aspect makes a transition to an architecture prefix easier, as the evaluation of $0 could be used to override the host* variables defined near its top. All that it needs would be clever symlinking. > Reasoning about multiarch can be hard work and I'm running low on > coffee. Would anyone like to pick holes in this analysis? Having a multiarch background, but no libtool background, I tried to understand it. I did not find any obvious flaws, but I do note that with option 2.1, having libtool depend on libtool-bin does not conceptually make sense to me, even though this alternative may be practically useful. Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140112153959.ga8...@alf.mars