diff options
author | Dan McGee <dan@archlinux.org> | 2008-10-16 19:47:54 -0500 |
---|---|---|
committer | Dan McGee <dan@archlinux.org> | 2008-10-28 22:18:22 -0500 |
commit | a63aeed562c8bdd6604ec50e6a4b684f6edabda3 (patch) | |
tree | f5f1b8d3a38b87e07159b1b670222fc7a9759bf8 /contrib/updatesync | |
parent | 2f5d7927254a760a54282d70c827768c56c657b7 (diff) | |
download | pacman-a63aeed562c8bdd6604ec50e6a4b684f6edabda3.tar.xz |
Give pacman-optimize a refresher
This patch addresses quite a few lingering issues in the pacman-optimize
script. FS#11767 provoked this look-over and the following issues were
noticed and fixed:
* If an alternate dbroot was specified, then the lockfile location was never
updated to reflect it. The lockfile location is now set after all dbpath
initialization.
* The inclusion of a trailing slash on dbroot was problematic and led to the
following command being executed:
bsdtar -xpf /tmp/pacman-optimize.p12Q4vAUWY/pacman-db.tar.gz \
-C /var/lib/pacman/.new/
It is doubtful we meant to create a hidden directory like this below our
database root, only to go and delete it a second later and then
re-extract. Fix the whole thing by ensuring our dbpath has its trailing
slash stripped and then appending it when necessary.
* The DB extraction was performed twice for no real apparent reason. This
opens the door for extraction problems the second time around, leaving you
with no original database to fall back to. Change the behavior so we only
extract once, and then perform a directory shuffle once we verify the
checksums are correct.
* Perform an explicit sync after we drop the new database on the disk. It
should work better this way.
* Tighten up our check for a pacman lockfile and the time we create one.
There is still a possible race condition but the window is shorter.
Signed-off-by: Dan McGee <dan@archlinux.org>
Diffstat (limited to 'contrib/updatesync')
0 files changed, 0 insertions, 0 deletions