In bug #695229, I noted that an Architecture: all package really should be Multi-Arch: foreign. This led to an IRC discussion between Goswin, Steve L. and me in which I formulated the proposal:
If a package is 'Architecture: all', and all its dependencies are 'Multi-Arch: foreign' (including the case where there are no dependencies), this package should implicitly be treated as 'Multi-Arch: foreign' as well. Steve asked what the impact would be, given that Multi-Arch: foreign only matters if you have reverse dependencies that are not Architecture: all. So I wrote a crude script to figure it out. The numbers depend on whether you consider only Depends + Pre-Depends, or if you also consider Recommends and Suggests. Explicit M-A:foreign | Implicit M-A:foreign +---------------------+--------------------- | With | With | Total | All non-arch:all | All non-arch:all Rule variant | | rev-dep(s) | rev-dep(s) ----------------------+-------+---------------------+--------------------- Depends + Pre-Depends | 17339 | 580 145 | 5310 994 Dep + P-D + Rec + Sug | 17339 | 580 197 | 2969 1151 Now, whether to consider Recommends and Suggests in the calculations, I don't have a strong opinion. It does change the mix of packages. For example: - bash-completion could be implicitly M-A:foreign, but this only really "matters" if we consider Recommends + Suggests. Almost nothing Depends on it, but several arch:any packages Recommend or Suggest it. - aptitude-common is implicitly M-A:foreign only if we do _not_ consider Recommends + Suggests, because while it has no dependencies, it Recommends aptitude, which is not M-A:foreign. - alsa-base is implicitly M-A:foreign only if we do _not_ consider Recommends, because while it only Depends on packages which are M-A:foreign, it Recommends alsa-utils, which is not. Anyway, these numbers indicate to me that it may be worth patching dpkg, apt, aptitude and other deb + multi-arch aware tools, to implicitly mark all those Arch:all packages as Multi-Arch:foreign, so that this doesn't have to be done explicitly. (But not during the freeze.) Thoughts? -- 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/20121206080512.gl4...@p12n.org