Send patches - preferably formatted by git format-patch - to patches at archlinux32 dot org.
summaryrefslogtreecommitdiff
path: root/contrib/README
diff options
context:
space:
mode:
authorDan McGee <dan@archlinux.org>2008-10-16 19:47:54 -0500
committerDan McGee <dan@archlinux.org>2008-10-28 22:18:22 -0500
commita63aeed562c8bdd6604ec50e6a4b684f6edabda3 (patch)
treef5f1b8d3a38b87e07159b1b670222fc7a9759bf8 /contrib/README
parent2f5d7927254a760a54282d70c827768c56c657b7 (diff)
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/README')
0 files changed, 0 insertions, 0 deletions