Johannes: thanks for raising this issue here. Following yours and Pietro's experiments I was about to post something along the same lines, but you relieved me of that duty: thanks :-) On Thu, Sep 13, 2012 at 04:26:03PM -0700, Russ Allbery wrote: > > That does sound like a bug. The intuitive behavior when foo both > > Provides and Conflicts with bar would be for the Conflicts to only > > apply to other packages. > Indeed. This particular combination of package metadata has a specific > meaning defined in Policy 7.4: […] > their own package name, or with a virtual package which they provide > (see below): this does not prevent their installation, and allows a > package to conflict with others providing a replacement for it. You > use this feature when you want the package in question to be the only > package providing some feature. > > So you need to specifically recognize the case of Conflicts naming the > package itself or a virtual package that this package provides, and in > that case the Conflicts should not be applied to that package for > installability determination. > > None of this language has, as yet, been updated for multiarch, but I think > it makes logical sense for a M-A: same package to be coinstallable even if > it Conflicts with its own package name or a virtual package it Provides, > by extension from the intention of this construct without multiarch. 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). 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. According to the attached tests (which are courtesy of Pietro Abate), it seems that APT does ignore self-conflict across arch boundaries when they are via virtual packages (test 1), but it doesn't ignore them when they are via real packages (test 2). Looking on a random "desktop-like" laptop machine with various suites, we've found ~200 packages which declare self-conflicts on their real names (probably due to historical package renaming, that have remained around). None of them is M-A: same, so the above alleged APT issue is only theoretical at this point. But it might become real with the increasing popularity of multiarch-ed packages in the Debian archive. If you could review the above and confirm it's an APT issue, I'll be happy to file a bug report (but I can't promise a patch :-P). TIA, Cheers. -- Stefano Zacchiroli . . . . . . . zack@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Packages
========
Package: a1
Version: 1
Architecture: arch1
Multi-Arch: same
Provides: ap
Conflicts: ap
Package: a1
Version: 1
Architecture: arch2
Multi-Arch: same
Provides: ap
Conflicts: ap
Package: a2
Version: 1
Architecture: arch1
Multi-Arch: same
Conflicts: a2
Package: a2
Version: 1
Architecture: arch2
Multi-Arch: same
Conflicts: a2
Package: a3
Version: 1
Architecture: arch1
Multi-Arch: same
Package: a3
Version: 1
Architecture: arch2
Multi-Arch: same
Test 1
======
$./fakeapt.sh test install a1:arch1 a1:arch2
[...]
The following NEW packages will be installed:
a1 a1:arch2
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Inst a1 (1 localhost [arch1])
Inst a1:arch2 (1 localhost [arch2])
Conf a1 (1 localhost [arch1])
Conf a1:arch2 (1 localhost [arch2])
Test 2
======
$./fakeapt.sh test install a2:arch1 a2:arch2
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
a2 : Conflicts: a2:arch2 but 1 is to be installed
a2:arch2 : Conflicts: a2 but 1 is to be installed
E: Unable to correct problems, you have held broken packages.
Test 3
======
$./fakeapt.sh test install a3:arch1 a3:arch2
[...]
The following NEW packages will be installed:
a3 a3:arch2
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Inst a3 (1 localhost [arch1])
Inst a3:arch2 (1 localhost [arch2])
Conf a3 (1 localhost [arch1])
Conf a3:arch2 (1 localhost [arch2])
Attachment:
fakeapt.sh
Description: Bourne shell script
Attachment:
signature.asc
Description: Digital signature