Hi Eli,
Dangerous is when you break your system by installing incompatible packages via a "successful" partial update.
Ah, right. I `pacman -S foo'. foo depends on libbar. libbar 1.0 is already installed because xyzzy needs it. The earlier `pacman -Syuw' updated the local database to know libbar 1.1 is available thus installing foo upgrades libbar. xyzzy remains at the old version, incompatible with libbar 1.1.
Can an attempt to fetch an old, now missing, package still occur even with `pacman -Sy pkgname' because the remote database has been altered, and old versions removed, between the -y's refresh and fetching a long list of packages?
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. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy