For example:

allan@mugen ~

...

sudo touch /var/lib/pacman/db.lck Password:

allan@mugen ~

...

pacman -Syu :: Synchronizing package databases... error: failed to update allanbrokeit (unable to lock database) error: failed to update kernel64 (unable to lock database) error: failed to update testing (unable to lock database) error: failed to update core (unable to lock database) error: failed to update extra (unable to lock database) error: failed to update community-testing (unable to lock database) error: failed to update community (unable to lock database) error: failed to synchronize any databases

allan@mugen ~

...

pacman -U /var/abs/local/pacman-git/pacman-git-20110828-1-i686.pkg.tar.xz error: failed to init transaction (unable to lock database) if you're sure a package manager is not already running, you can remove /var/lib/pacman/db.lck

Allan

Well, in fact "pacman -Su" is consistent with "pacman -U". Here the inconsistency is between "pacman -Sy" and "pacman -U", because -Sy is not a transaction, and alpm locks/unlocks the database in every alpm_db_update() call, and all attempts fail in this case. I don't see any clean solution to this: We can "predict" that all database update will fail (which is theoretically not always true, but it has very high probability) and do some hackish things, or modify alpm_db_update's parameters to get an alpm_list of databases, but then the error handling would be more complicated. If consistency is so important, we could implement a check_db_lock stuff similar to our needs_root()/check_root stuff (I guess this needs alpm work too), and pacman could do this check before doing anything (if it is necessary, which can be calculated from command-line arguments). [But of course, alpm db-lock check should be also kept in this case. This would be just an extra check, called from front-end.] But I am fine with the current output. NG