Re: M-A: Same package A providing and conflicting with package B
Stefano Zacchiroli <zack@debian.org> 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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: