summaryrefslogtreecommitdiffstats
path: root/scripts/po/pacman-scripts.pot
diff options
context:
space:
mode:
authorPang Yan Han <pangyanhan@gmail.com>2011-08-29 18:58:48 +0200
committerDan McGee <dan@archlinux.org>2011-08-30 03:17:08 +0200
commit2c5f000d5b2fd5db3b70670b835e6b932c0d10e3 (patch)
tree4bd8f0e39cd351a007d9cb46723b69f3b7561697 /scripts/po/pacman-scripts.pot
parent234b6ffc2c39268d1efdc414e02bc4b352e5d931 (diff)
downloadpacman-2c5f000d5b2fd5db3b70670b835e6b932c0d10e3.tar.gz
pacman-2c5f000d5b2fd5db3b70670b835e6b932c0d10e3.tar.xz
Improve advice for sync ops when db.lck is present
When the database is locked, sync operations involving transactions, such as pacman -Syy, show the following: :: Synchronizing package databases... error: failed to update core (unable to lock database) error: failed to update extra (unable to lock database) error: failed to update community (unable to lock database) error: failed to update multilib (unable to lock database) error: failed to synchronize any databases Whereas pacman -U <pkg> shows: 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 Which is much more meaningful, since the presence of db.lck may indicate an erroneous lockfile instead of an ongoing transaction. Improve the error messages for sync operations by advising the user to remove db.lck if he is sure that no package manager is running. Signed-off-by: Pang Yan Han <pangyanhan@gmail.com> Signed-off-by: Dan McGee <dan@archlinux.org>
Diffstat (limited to 'scripts/po/pacman-scripts.pot')
0 files changed, 0 insertions, 0 deletions