allan at archlinux.org
Thu Feb 16 03:17:26 EST 2012
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.
:: The following packages should be upgraded first :
:: Do you want to cancel the current operation
:: and upgrade these packages now? [Y/n]
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
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?
More information about the pacman-dev