Bug 529719

Description of problem:

This problem is outlined and patched upstream:

http://yum.baseurl.org/ticket/296


When comparing two packages that provide a dependency, a package with an alternate name does not get selected even though it is the best match to resolve a dependency.  For example, installing packages from a 3rd party repo such as IUS: (http://dl.iuscommunity.org/pub/ius).  These packages have alternate names such as php52, php53, mysql50, mysql51 ... and do not obsolete (can only be explicitly installed to replace stock packages).  Consider the following situation:

php52, php52-common, php52-cli are installed in place of stock packages.  End user issues the command 'yum install cacti' which requires php-mysql, php-snmp, etc.  Even though php52 is installed and php52-mysql (in the 3rd party repo) provides php-mysql and is obviously the better choice, Yum attempts to resolve the dependency with the stock RHEL packages (not what the user wants).  Yum should properly resolve php52-mysql as the best provider of the dependency based on the fact that php52 (its base package) is installed and presumably 'preferred'.


Version-Release number of selected component (if applicable):

3.2.19-X


How reproducible:

Every time



Steps to Reproduce:
1. Install packages with an alternate name that replace a stock package
2. Install a stock package that requires something that a 3rd party, alternate package name, provides (yum requires php-mysql, provided by php52-mysql (not yet installed))
3. Fail.
  

Actual results:

Yum resolves the stock RHEL package for the dependency rather than the better choice based on the fact the other packages base package is already installed (preferred).


Expected results:

Yum should award points to the alternative name package (or any package) if that packages base package is installed (meaning the user made the choice to install the 3rd party software and is therefore preferred over the stock package).


Additional info:

It is understood that RedHat does not support 3rd party repos, however consider the fact that this enables a user to safely use alternative repositories that replace RHEL packages in a safe way (see http://wiki.iuscommunity.org/SafeRepoInitiative).  The alternative is using repos that automatically override stock RHEL and force users to upgrade everything... or alternative package names that obsolete stock RHEL (also not preferred).

The ideal resolution of this ticket is that the changes listed in the upstream yum tracker above would be backported to RHEL 5.5.