[pacman-dev] dbs should be locked between _alpm_db_open and _alpm_db_close

Nagy Gabor ngaba at bibl.u-szeged.hu
Sat Sep 22 05:24:27 EDT 2007


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/





More information about the pacman-dev mailing list