Hey guys, Hopefully someone has some insight, but I fear that this involves some pretty intimate knowledge with the alpm dirty internals. I implemented the local DB "version" check as something on the transaction process, due to the fact that we call get_pkgcache or find_package and all those fun methods all over the place with the expectation that they normally won't fail in any way. This was a bit of a hack, and has become more apparent as I look at some of the GPG issues. Due to the lazy loading of the package cache for databases, we never really know when a database may be initialized, or which call site will do so. This makes it hard for us to 1) do the local DB sanity check ASAP and in the right place, and 2) implement signature checking on databases each time it is accessed, which seems like the prudent decision to me. That leaves us with a few options: 1) Don't check database signatures every time, only when we "need to", e.g. right after download. Not a fan of this one. 2) Only check database signatures if we go through the transaction layer- just like we do now with the local version check. 3) Add some explicit alpm_dbs_set_in_stone() method that needs to be called before databases can be used, but after they are registered, that takes care of some bookkeeping stuff like this. Stinks because it introduces a rather kludgy API that depends on methods being called in procedural order (not to mention all frontends will need modification), but by far the easiest way to resolve this. 4) Fix callsites everywhere that may force a load of the pkgcache to actually check error return values for the "local db too old" and "gpg sig check failed" cases, among other, rather than just assuming the pkgcache is NULL without looking at pm_errno. Best solution as it requires no API change, but will definitely have a large LOC impact. Thoughts? -Dan