Bug 1302785

Packages should only requires "apc" when they use the apc API, which is provided by apcu (or apcu-bc for newer version).

To summarize:

If a package requires php-pecl-apcu, php-pecl-apc will be pulled by yum (exact name match)

If a package requires php-pecl(APC), both packages provide this, and yum will select... apcu.

If a user "prefer" the dead unstable / unmaintained php-pecl-apc package he can install it "before" the dependent package.

As a workaround exists, and the virtual provides are needed to give user the choice, I don't plan to remove them.

Remi, this bug report is not about whether the php-pecl-apc package is dead, unstable or unmaintained (we are in agreement there). but about the fact that apcu will install when apc is required.

According to https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy_for_Conflicting_Packages packages must never conflict with Base packages, and in this case it clearly does.

Of course, I mean

If a package requires "php-pecl-apc", "php-pecl-apc" will be pulled by yum (exact name match)

Just for memory, from https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy_for_Conflicting_Packages

" EPEL packages can conflict with packages in other RHEL channels. "

php-pecl-apc is only available in the optional channel (not in base).

we can probably leave it as-is and for opcode caching either install php-pecl-apc first by name or additionally include php-pecl-zendopcache if opcode cache is required

> If a package requires "php-pecl-apc", "php-pecl-apc" will be pulled by yum (exact name match)

No, it won't.  Yum only gives more points during resolution for exact name match if you are installing that package.  That is why `yum install php-pecl-apc` works.  When another package requires php-pecl-apc as David described, the exact name match doesn't make a difference, and the dependency resolves to php-pecl-apcu from EPEL due to the virtual provides.

> php-pecl-apc is only available in the optional channel (not in base).

According to https://infrastructure.fedoraproject.org/repo/json/pkg_el6.json, it is available in base and optional.

channel: [
    "rhel-i386-server-6",
    "rhel-i386-server-optional-6",
    "rhel-ppc64-server-6",
    "rhel-ppc64-server-optional-6",
    "rhel-x86_64-server-6",
    "rhel-x86_64-server-optional-6"
]

php-pecl-apcu-4.0.11-2.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-b2fc67572d

php-pecl-apcu-4.0.11-2.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-b2fc67572d

php-pecl-apcu-4.0.11-2.el6 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-b2fc67572d

The offending provides have been removed in 4.0.11-2.el6, so the original purpose of this bug has been fixed.  However, it still conflicts with php-pecl-apc in base, which is a violation of EPEL policy.

# repoquery --enablerepo epel-testing --conflicts php-pecl-apcu-4.0.11-2.el6.x86_64
php-pecl-apc < 4

"EPEL packages must never conflict with packages in RHEL Base (Including Advanced Platform)." - https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy_for_Conflicting_Packages

@Carl If you really think is not acceptable, please raise a EPEL steering Committee ticket.

I think it is good to give user the choice among various cache (apc, apcu, xcache, opcache).

I EPEL S.C. states this is not acceptable, I will remove all alternative caches.

php-pecl-apcu-4.0.11-2.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.