With {Project}, using incremental updates to your Content Views solves some repository dependency problems. However, dependency resolution at a repository level still remains problematic on occasion.
When a repository update becomes available with a new dependency, {Project} retrieves the newest version of the package to solve the dependency, even if there are older versions available in the existing repository package. This can create further dependency resolution problems when installing packages.
A repository on your client has the package example_repository-1.0
with the dependency example_repository-libs-1.0
.
The repository also has another package example_tools-1.0
.
A security erratum becomes available with the package example_tools-1.1
.
The example_tools-1.1
package requires the example_repository-libs-1.1
package as a dependency.
After an incremental Content View update, the example_tools-1.1
, example_tools-1.0
, and example_repository-libs-1.1
are now in the repository.
The repository also has the packages example_repository-1.0
and example_repository-libs-1.0
.
Note that the incremental update to the Content View did not add the package example_repository-1.1
.
Because you can install all these packages using yum, no potential problem is detected.
However, when the client installs the example_tools-1.1
package, a dependency resolution problem occurs because both example_repository-libs-1.0
and example_repository-libs-1.1
cannot be installed.
There is currently no workaround for this problem. The larger the time frame, and minor Y releases between the base set of packages and the errata being applied, the higher the chance of a problem with dependency resolution.