Hi! The problem bellow doesn't appear with the current dummy front-end, but if you want to design a flexible alpm lib, you have to deal with it. The main problem, that the whole pkgcache concept _assumes_ that the db won't be modified by other processes. However, pacman locks db iff he modifies it, so he cannot trust his assumption. Let me explain. Imagine a nice pacman GUI which starts with alpm_initialize, opens the databases and let user do multiple operations. pacman_gui can run all the day, without unregistering the databases, alpm_release etc. etc. The main problem, that if pacman_gui (== libalpm) let an other pacman instance to modify the local db, he should always reload the pkgcache, because it may be outdated! So the following situation can happen: pacman_gui loaded the pkgcache to list the available local packages to the user, and now he is waiting. During this an other pacman instance removed lot of packages (he could lock anf unlock the db, since pacman_gui didn't lock anything yet) and exited. pacman_gui didn't detect anything from this. Now the user ask pacman_gui to install some packages: now he locks the dbs, but he trust its outdated pkgcache: for example its depchecks will use this outdated information... So _alpm_db_open should lock database, and _alpm_db_close should unlock it. The problem here, that now a non-root user cannot write /var/lib/pacman/local/db.lck, but we can solve this somehow. (Note, that I'm suggesting a lock-per-db method here.) Another (not-so-strict but slower) possible solution a .lastupdate-like method to detect if the database was modified or not after pkgcache load, and reload if needed. Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/