[pacman-dev] some notes + new pactest file

Xavier shiningxc at gmail.com
Sun Jun 10 18:16:25 EDT 2007

2007/4/24, Nagy Gabor <ngaba at petra.hos.u-szeged.hu>:
> Hi!
> 1. As I see, can_remove_package should be replaced with direct call of
> _alpm_checkdeps with TRANS_TYPE_REMOVE + check the reason flag
> by hand, because the dependency check is not really sophisticated in
> this function /and reimplemented/ .
> 2. _alpm_checkdeps doesn't really need trans param (neither in my
> patched version nor the original imho <- its usage in cvs version
> is messy for me)
> 3. Some words about speed again: We must make the "usual" decision
> again:
> a.) We prefer speed: we don't care about the fact
> multiple provisions can exist on the system and we don't let pacman
> remove the provision even if other package provides it too (current
> state).
> b.) We prefer "perfection": this is notably slower of course (if only
> if the current version reports: package cannot be removed)
> 4. I repeat myself: all dependency check stuff from sync.c should be
> moved (and rewritten) to deps.c.
> 5. That is very common in libalpm, that we search for a
> depend-satisfyer, in most cases we forget check version number or
> provides etc., so I think a "search_for_satisfyer" function would
> vanish these bugs and reduce redundancies in the source (it's just a
> for "pkg in pkgcache" alpm_depcmp(pkg,depend)). To show this, here is a
> sync300.py file (see _alpm_resolvedeps for the "negligent"
> search_for_satisfyer):
> ----------
> Bye, ngaba
> ----------
> self.description = "Corrupt database (broken deps)"
> sp1 = pmpkg("pkg1")
> sp1.depends = ["pkg2=1.0-2"]
> self.addpkg2db("sync", sp1)
> sp2 = pmpkg("pkg2", "1.0-1")
> self.addpkg2db("sync", sp2)
> self.args = "-S %s" % sp1.name
> self.addrule("PACMAN_RETCODE=1")
> self.addrule("!PKG_EXIST=pkg1")
> self.addrule("!PKG_EXIST=pkg2")

I would love to see patches for all of these points too :)
(at least, if you see a clean/correct way to do it)
Maybe at least for 5. , since you provided a testcase, and that you
say the code could be cleaned up while fixing it.


More information about the pacman-dev mailing list