I was thinking about SyncFirst today and decided we need a good summary of what the issues are and why the current and old implementations fail. Why the current (pacman-4.0) implementation fails: When a package in SyncFirst is to be updated, pacman will update that first and pull everything in its dependency tree that needs updated. If a package not being updated has a strict versioned dependency on a package that is being updated, this results in an error. e.g. :: The following packages should be upgraded first : pacman :: Do you want to cancel the current operation :: and upgrade these packages now? [Y/n] resolving dependencies... looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: gcc: requires gcc-libs=4.6.2-6 Here pacman tries to pull the gcc-libs update as a dependency of the SyncFirst package (pacman). gcc requires a specific version of gcc-libs so this update fails. Q. If this does not involve provides, why has this only been reported with multilib? A. multilib users are stupid. Why the old (pacman-3.5) implementation fails: The SyncFirst packages are updated on their own and only the dependencies it explicitly requires. This can cause failures as if an update of a dependency is not pulled and the package in SyncFirst really needs those updates too. e.g. issues that occurred when pacman was updated and glibc was not but pacman required symbols in the newer glibc. This can be partly worked around by using versioned dependencies, but that can lead to the same issue. e.g. if a new pacman release is made just after gcc-4.7 is released and we add a versioned dep on gcc-libs>=4.7, we end in exactly the same situation as current. So how could we fix this? Here is my proposal... It may be impossible to implement: Firstly, do not split then stop the transaction when hitting a SyncFirst package. Instead do all downloads/conflict checks/dependency checks and then in the first instance install the packages that currently are installed in SyncFirst (i.e. the SyncFirst package and all its deps that need updated) ignoring dependency issues and then - without stopping - install the rest of update. Would that be possible? Allan