Nagy Gabor wrote:
Hi!
I know that I speak too late, but I haven't time/motivation to review
this patch nowadays.
1. See alpm/sync.c/sync_prepare(). When user decides to remove
unresolvable targets from the list, our code doesn't remove any targets
from target->packages, just adds the pulled dependencies. The actual
removal is done in the sortbydeps part (sortbydeps is called with list
param!). This works, but it is hard to understand (imho), and it is a
memleak: some pmsyncpkg_t structs magically disappeared.
I don't think that it's confusing that it happens this way; the resolve
operation builds up a new list of packages for the transaction, and that
list is then used to replace the trans->packages list. This is opposed
to before where the resolve operation modified trans->packages in place.
You are right that there is a memory leak there, though; my change
failed to free up any pmsyncpkg_t structs which were in trans->packages
but were not in the replacement list. I will submit a small and simple
patch which fixes this issue shortly.
Good catch!
2. Behaviour change (this pactest now fails)
--- sync993.py ---
self.description = "Choose a dependency satisfier (target-list vs. database)"
sp1 = pmpkg("pkg1")
sp1.depends = ["dep"]
sp2 = pmpkg("pkg2")
sp2.provides = ["dep"]
sp3 = pmpkg("pkg3")
sp3.provides = ["dep"]
for p in sp1, sp2, sp3:
self.addpkg2db("sync", p)
self.args = "-S pkg1 pkg3"
self.addrule("PACMAN_RETCODE=0")
self.addrule("PKG_EXIST=pkg1")
self.addrule("!PKG_EXIST=pkg2")
self.addrule("PKG_EXIST=pkg3")
------------------
If you define conflict between pkg2 and pkg3, pacman will refuse to
commit the transation. Before this patch, pacman always chose from
target list.
sync993 does not exist in the pacman sources. If it did, I would have
seen this problem and addressed it. I will get back to you on this once
I have figured out what's going on (I suspect that it's a difference in
the way the new resolve code works, it may stop too short now to figure
out that there is a 'better' package to choose for resolving the
dependency).
Thanks,
Bryan
_______________________________________________
pacman-dev mailing list
[email protected]
http://www.archlinux.org/mailman/listinfo/pacman-dev