[pacman-dev] Fix reason handling before 3.1 (was: Final steps before 3.1 release)

[Xavier]

On Mon, Dec 03, 2007 at 06:08:08PM +0100, Nagy Gabor wrote:
> 2. this needs sync.c (pmsyncpkg_t) rework, but currently sync.c is so
> hard-to-understand that I don't want to do this.
> 

If you are referring to your pending sync.c patch, here is the situation :
* your original patch breaks the sync040, sync041 and sync990 patch
-> that might not be acceptable (at least Dan doesn't accept it :))
* my modified version of it breaks sync893, sync897, sync898, sync992 and
sync999.

Dan agreed that sync893 and sync897 pactests were weird and could be changed,
but not the last 3 (btw, if we change these two pactests now, then applying
my modified version of Nagy's patch won't make a big difference :
3 broken pactests instead of 2).

But my opinion is that pacman shouldn't even try to guess which package the
user wants when it can't know for sure, and that it should be left to the
user to decide.
Two possibilities for that :
1) interactively ask the user (not a real problem, but it's less easy to test
this with pactests)
2) pacman fails and displays the package conflicts (the user can fix it using
-S / -R)

So let's have a look at the 3 problematic pactests.

1) sync898

---------------------------------------------------------------------
self.description = "System upgrade with conflicts and provides"

sp1 = pmpkg("pkg1", "1.0-2")
sp1.conflicts = ["pkg2"]
sp1.provides = ["pkg2"]
self.addpkg2db("sync", sp1);

sp2 = pmpkg("pkg2", "1.0-2")
self.addpkg2db("sync", sp2)

lp1 = pmpkg("pkg1")
self.addpkg2db("local", lp1)

self.args = "-S %s" % " ".join([p.name for p in sp1, sp2])

self.addrule("PACMAN_RETCODE=0")
self.addrule("PKG_MODIFIED=pkg1")
self.addrule("!PKG_EXIST=pkg2")
---------------------------------------------------------------------


The user tries to install sp1 and sp2, but these two packages conflict
together. How does pacman know the user wouldn't prefer pkg2 over pkg1?
If pacman just failed, then the user would have to make the decision, and
either run "pacman -S pkg1" or "pacman -S pkg2".

2) sync 992

---------------------------------------------------------------------
self.description = "Sync a package pulling a conflicting dependency"

sp1 = pmpkg("pkg1")
sp1.depends = ["pkg3"]

sp2 = pmpkg("pkg2")

sp3 = pmpkg("pkg3")
sp3.conflicts = ["pkg2"]
sp3.provides = ["pkg2"]

for p in sp1, sp2, sp3:
	self.addpkg2db("sync", p)

lp1 = pmpkg("pkg2", "0.1-1")
self.addpkg2db("local", lp1)

self.args = "-S %s" % " ".join([p.name for p in sp1, sp2])

self.addrule("PACMAN_RETCODE=0")
self.addrule("PKG_EXIST=pkg1")
self.addrule("!PKG_EXIST=pkg2")
self.addrule("PKG_EXIST=pkg3")
---------------------------------------------------------------------


Well same problem here. The user asked for pkg1 and pkg2, yet pacman
installed pkg1 and pkg3, and removed pkg2.
What if pkg2 was more important? (and superior the the pkg3 provider)

Other than that, I think this a strange situation.
If pkg3 provides pkg2, it's usually because the other packages depend on pkg2
(yet pkg1 depends on pkg3 here, instead of pkg2).

3) sync 999

---------------------------------------------------------------------
self.description = "System upgrade"

sp1 = pmpkg("pkg1", "1.0-2")
sp1.conflicts = ["pkg2"]
sp1.provides = ["pkg2"]
self.addpkg2db("sync", sp1);

sp2 = pmpkg("pkg2", "1.0-2")
self.addpkg2db("sync", sp2)

lp1 = pmpkg("pkg1")
self.addpkg2db("local", lp1)

lp2 = pmpkg("pkg2")
self.addpkg2db("local", lp2)

self.args = "-Su"

self.addrule("PACMAN_RETCODE=0")
self.addrule("PKG_EXIST=pkg1")
self.addrule("!PKG_EXIST=pkg2")
---------------------------------------------------------------------


And same problem here again, I don't understand why pacman has to choose pkg1
over pkg2..

Seems like pacman always prefer the package conflicting / providing the
other. I can't understand why, because there is a (common?) situation where
this doesn't make any sense : the mplayer-svn / mplayer one.

If pacman really had to choose between both, it should rather pick the stable
package, instead of the development one.