On 14/05/13 23:37, Colin Watson wrote: > I don't understand how graphviz itself could possibly be Multi-Arch: > same. Things like libgraph4, sure, but you can't make a package that > ships compiled code in /usr/bin/ M-A: same - builds on different > architectures will inevitably clash - and it wouldn't really be very > useful to try. > > M-A: same is normally for packages containing libraries and such, not > for packages containing executables on $PATH. I certainly encourage you > to make libraries M-A: same wherever possible, but it's orthogonal to > this bug. Ah, now I understand. I was indeed referring to making the libraries Multi-Arch:same, not the main graphviz package.
Hmm, so the idea is that you might be, for example, cross compiling doxygen for sparc on a x86 machine, and you want the dependancy on graphviz to match to the x86 graphviz which might already be installed - something along those lines? ISTM the same logic could apply to quite a large number of other packages. Usage of Multi-Arch:foreign in the documentation I've seen (primarily http://wiki.debian.org/Multiarch/Implementation) seems to focus more on support packages within the same source package, rather than this apparently more extensive usage. Has there been any discussion around this sort of use on -devel to your knowledge? Just be clear, I'm not particularly against marking graphviz M-A:foreign, but my concern is if the same logic could apply to lots of other packages, then it would be nice to see some sort of consensus that this is the Right-Thing-To-Do(tm) OTOH, it's late in my timezone, so I might just not be thinking clearly ;-) Cheers, David. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
