FS#8897 - Some asymmetries of the current conflict resolving
Attached to Project:
Pacman
Opened by Nagy Gabor (combo) - Tuesday, 11 December 2007, 15:47 GMT
Last edited by Dan McGee (toofishes) - Sunday, 27 January 2008, 18:16 GMT
Opened by Nagy Gabor (combo) - Tuesday, 11 December 2007, 15:47 GMT
Last edited by Dan McGee (toofishes) - Sunday, 27 January 2008, 18:16 GMT
|
Details
Well, I don't like provide == depend case at all, but I set
rules to show your expected result.
Pactests attached. |
This task depends upon
Closed by Dan McGee (toofishes)
Sunday, 27 January 2008, 18:16 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed by commit 88cbee3c24768470cc0d4abe050e98b989807a67
Sunday, 27 January 2008, 18:16 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed by commit 88cbee3c24768470cc0d4abe050e98b989807a67
sync1007.py
------sync1009.py------
self.description = "Provide == conflict (3)"
sp1 = pmpkg("pkg1")
sp1.conflicts = [ "pkg2" ]
sp1.provides = [ "pkg2" ]
self.addpkg2db("sync", sp1)
sp2 = pmpkg("pkg2")
sp2.conflicts = [ "pkg1" ]
self.addpkg2db("sync", sp2)
self.args = "-S pkg2 pkg1"
self.addrule("PKG_EXIST=pkg1")
self.addrule("!PKG_EXIST=pkg2")
------------------------
I hope that this indicates better then the current conflict resolving _depends on_ the order of packages in the target list (see sync1007.py vs. sync1009.py)
However, I don't understand what is the reasoning behind this behavior, as I previously said there:
http://www.archlinux.org/pipermail/pacman-dev/2007-December/010393.html
And sync1007 passes, sync1009 fails; this is really ugly.
This is very odd indeed..