On 11/8/18 1:05 PM, Ralph Corderoy wrote:
It won't be old and now missing, because you used -Sy and it will refresh *again*.
But isn't it multiple stages with a race condition?
1 Update /var/lib/pacman/sync/core.db 2 Update /var/lib/pacman/sync/extra.db 3 Update /var/lib/pacman/sync/community.db 4 Update /var/lib/pacman/sync/multilib.db 5 Create /var/cache/pacman/pkg/foo-1.0.pkg.tar.xz 6 Create /var/cache/pacman/pkg/bar-2.0.pkg.tar.xz 7 Create /var/cache/pacman/pkg/xyzzy-3.0.pkg.tar.xz
Can the remote core.db be updated between 1 and 6 because bar 2.1 is available? Do bar-2.0.pkg.tar.xz and bar-2.1.pkg.tar.xz ever exist at the same time? Perhaps the fetch of bar-2.0.pkg.tar.xz might fail because it's been removed by the time it's attempted.
This is nothing to do with my original question. :-) I guess I'm asking how is a consistent multi-file database of indexes and `records' presented? It might be that the rare times this happens, the user just runs `pacman -Sy pkgname' again.
Well, most users will have multiple mirrors in their pacman mirrorlist. So if the package is no longer available on the first mirror, pacman will keep trying until it finds it somewhere. Also, the job we use to delete old packages only runs at 3-hour intervals, which means there's a window of opportunity when multiple versions are still available, and most mirrors sync roughly hourly but not on the same minute of that hour. So it would be an odd coincidence if you managed to mistime your update such that 1) your mirror updates in the seconds between syncing the db and downloading the package 2) that mirror update is during its one-hour sync cycle that is also the one-third of the time when the cleanup job runs 3) every one of your fallback mirrors is newer than your first configured mirror If you do manage to win this game of roulette, you can just pacman -Syu again. :) pacman will simply abort the upgrade if it cannot find one of the package files, so consistency is maintained -- it's just a much more exotic case of "I haven't done pacman -Syu in a week and cannot install new packages that have been updated on the mirrors". ... Source: ansible repo containing our dbscripts role, and in particular, the job cleanup.{service,time} : https://git.archlinux.org/infrastructure.git/tree/roles/dbscripts/files The dbscripts cleanup script itself: https://git.archlinux.org/dbscripts.git/tree/cron-jobs/ftpdir-cleanup -- Eli Schwartz Bug Wrangler and Trusted User