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
