On Wed, May 15, 2013 at 12:36:39AM +0100, David Claughton wrote: > 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?
Yes, although not so much "which might already be installed" as that sbuild or other similar tools can choose to install the x86 version, simplifying the job and saving you from having to run graphviz under qemu or something. This is in fact very common when you attempt to cross-compile Debian packages; you generally want tools that are compiled but don't have architecture-dependent behaviour to be satisfied from the build (i.e. building-on) architecture rather than the host (i.e. building-for) architecture. Thanks to significant multiarch annotations to date and many other fixes in package build systems, it's possible to cross-compile quite a number of packages out of the box this way, far more than was achieved with previous approaches without significant out-of-tree patching. I don't have figures for Debian at the moment, but http://people.canonical.com/~cjwatson/cross/armhf/raring/ shows around a third of Ubuntu's "main" component, 464 out of 1362 source packages, cross-building cleanly. > 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) It's been applied to 655 packages already, so this is work that is well underway ... The earliest mention I can find is this, as long as you read "depend" liberally: http://web.dodds.net/~vorlon/wiki/blog/How_you_can_help_with_multiarch_today/ I can't seem to find a specific -devel thread to point you at right now, TBH because it doesn't really seem to have been controversial for some time as far as I know. We've been more or less assuming this approach in discussions about multiarch, cross-building, and architecture bootstrapping for a while now, since it's a natural and largely easy and safe way to improve the dependency graph in the context of the multiarch spec, and I wasn't aware that it had serious opposition. (There has been disagreement over the fine details of what to do with Architecture: all packages, but that's not at issue here.) I think it's just not mentioned in Multiarch/Implementation because converting standalone tools packages is fairly trivial by comparison with converting the combination of library packages and some common support packages. Realistically, to make the dependency arcs in question work properly with multiarch, you either have to mark a bunch of stuff as may-be-installed-from-foreign-architecture, or you have to mark a bunch of stuff as may-not-be-installed-from-foreign-architecture. The former approach is the more conservative one, allowing us to introduce support gradually without breaking things. For instance, the master multiarch spec (https://wiki.ubuntu.com/MultiarchSpec) says, under its list of discarded designs: Permit packages without Multi-Arch set to satisfy foreign dependencies An earlier draft suggested that packages without the Multi-Arch field set should be interpreted as satisfying dependencies in a cross-architecture manner. This was unsatisfactory because it would require a flag day to ensure that, when a package's dependency did need to be satisfied by a package of the same architecture, it was not incorrectly satisfied by an older, pre-multiarch version of the package. Now, it's true that cross-building expands the set of interesting packages somewhat. But there ends up being a lot of overlap between multiarch cross-building and the other things you might want to do with multiarch; for example, although I don't see one right now, it's easy enough to imagine a M-A: same library that calls graphviz utilities, and the fact that the same annotation handles both cases seems to me to be a good sign that the model is correct. The natural consequence of doing multiarch properly is that we ultimately end up with most packages (or at least most packages that have any reverse-dependencies) explicitly annotated with some multiarch behaviour, be it "same", "foreign", or "allowed". Unannotated packages are either leaf packages that don't matter, or they're on the to-do list. And yes, doing multiarch properly is a big job! Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
