Stefano Zacchiroli <[email protected]> writes: > Russ, thanks for clarifying the status of policy wording wrt multiarch. > I was well aware of Policy 7.4, but it wasn't clear to me whether > updating it wrt multiarch has (supposedly) already happened or not. Do > you want a bug report against policy about this? I did check the bug > listing, but I haven't found anything relevant to this specific issue (I > might have missed more generic multiarch bugs, though).
There has as yet been no work on Policy updates for multiarch. I'm hoping to be able to start working on that soon. I don't think there's a general bug for all Policy multiarch support (I should probably add one), just some more specific ones around the edges: #621050 Document dependencies needed to use multiarch paths #636383 10.2 and others: private libraries may also be multi-arch-ified #650974 Make Policy references to /usr/lib multiarch-aware #684672 document multiarch tuple definitions > But still, I could use double checking about the correctness of current > APT's behavior. From how Russ put it above, it shouldn't matter whether > the conflict is via a virtual package name or via a real package name: > self-conflicts across architecture boundaries should be ignored for M-A: > same packages. Yes, that's what I think would be a reasonable extension of the current language around how Conflicts works. If a package is explicitly tagged Multi-Arch: same, then to me that clearly implies that the maintainer thinks that multiple architectures of the package should be installable at the same time. Otherwise, the package would be tagged Multi-Arch: foreign or not be labelled for multiarch at all. If Conflicts prevents that, then the combination of a Conflicts on the package name and Multi-Arch: same would be a straight bug, since they would contradict each other. If we treat Conflicts on the package name the same as for a virtual package, then that combination becomes meaningful: it means that the package itself is co-installable, but can't be co-installed with any other package that Provides the same name. That seems more useful. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
