Hi Simon, On Sat, Sep 02, 2017 at 05:26:57PM +0100, Simon McVittie wrote: > That seems like it might be a bug (or design flaw if you prefer). If a > package (build-)depends on foo:any, it is saying "I am only using the > arch-indep parts of foo's interface", whatever those are.
You may call it feature. The idea here was that :any should not be used mindlessly. Thus it is only allowed on packages properly marked for that used with ``Multi-Arch: allowed``. In Build-Depends, you can mostly achieve the same effect with :native (which essentially is :any on any package (but Architecture: all packages (though our dependency resolvers don't agree here))). > Perhaps a dependency on foo:any by (for example) bar:mips should > always be satisfiable by foo:mips (as though the :any had been omitted), > regardless of foo's multi-arch status? This would bring it back to the > same meaning as omitting the :any, in the trivial case where only one > architecture is enabled. That proposal may ease meta data changes indeed. I suspect that it would also cause a lot of useless :any annotations. It's a two-sided sword. > Perhaps a dependency on foo:any should be satisfiable by any instance > of foo that is Multi-Arch: foreign? (In this case the :any is completely > redundant, because foreign sets up a similar situation from the other end) After studying Multi-Arch for many years now, I recognize that a core idea is to almost always flag the architecture constraint on the target of an edge. To understand this wicked sentence, consider a dependency graph and label each node (package) with an architecture. Now Multi-Arch says that by default every edge (dependency) must enforce equal architecture on both ends. Most of the header's job is relaxing this restriction. The designers of Multi-Arch decided that this relaxing should not be a property of the edges (e.g. :any), but a property of the dependee. Thus the current implementation ensures that :any cannot be used in situations where it is inappropriate. As you point out, that design is annoying for meta data transitions. > > > I think "the files installed by ``Architecture: all`` packages always > > > provide architecture-independent interfaces." is too broad. The counter > > > example is haskell-devscripts-minimal. This needs to be weakened > > > somehow. > > I would argue that these interfaces are architecture-independent from > the perspective of the package's (lack of) architecture. What they > are not independent of is the *build machine* architecture, just like > running uname -m or inspecting /proc/cpuinfo aren't independent of the > build machine architecture. This is certainly a problem for > cross-compilation, but it isn't the same issue as in dpkg or pkg-config, > where the architecture for which dpkg or pkg-config was built gets > hard-coded into its installed files (as the output of --print-architecture > or part of the default search path, respectively). That's a nice view, but it is not the view expressed by Multi-Arch. The meaning of the header considers the whole installation set as a unit. Whether you view this in a package building context or runtime context does not matter, what matters is whether the tools behave differently when you swap the architecture of underlying parts. As a side note, we marked pkg-config Multi-Arch: foreign, but that is technically wrong on another level. The marking would imply that it doesn't matter which architecture you use to supply the package. A prospective README.multiarch would need to say that you must not use plain pkg-config (without a triplet prefix). Yet that is what most packages do. If you perform an archive rebuild of pkg-config build-rdeps on amd64 in a chroot with preinstalled pkg-config:i386, the majority of builds will fail even though their Build-Depends are installable. This is another place where we bend the rules just to make it barely useful. For performing useful cross builds, one needs to discard host architecture instances of ``Multi-Arch: foreign`` packages. > > > For instance, the policy should make it > > > clear that marking libmdds-dev `Multi-Arch: foreign` (fictional, see > > > #843023) would be a policy violation. > > It is not clear to me that doing so *should* be a policy violation. If > libmdds-dev contains only headers (no shared or static library), and it > exposes architecture-independent libboost-dev headers (but no Boost > shared or static library), is there really anything wrong with having > libboost-dev from "the wrong architecture"? As long as everything is header-only, you can use ``Multi-Arch: foreign``. The thing is, even if libboost-dev was architecture-independent, it would expose libstdc++-7-dev. Since exposure is transitive, that carries over to libmdds-dev. Boost's dependency on libstdc++-4.8-dev | libstdc++-dev looks a bit strange though. Since libc++-dev provides libstdc++-dev (and no compiler will just use libc++-dev when it is installed without further options), that dependency looks essentially meaningless to me. So many bugs... It is less and less clear to me how to fix - let alone document - this mess. Helmut
