Bug 1302785

Summary: php-pecl-apcu claims to provide php-pecl-apc
Product: [Fedora] Fedora EPEL Reporter: David <david.bezemer>
Component: php-pecl-apcuAssignee: Remi Collet <fedora>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: el6CC: carl, fedora
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: php-pecl-apcu-4.0.11-2.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-21 05:19:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description David 2016-01-28 15:47:39 UTC
Description of problem:
php-pecl-apcu claims to provide php-pecl-apc which means that unless you use yum-priority any package that requires php-pecl-apc will install php-pecl-apcu from EPEL and as a result will run without OPCode caching


Version-Release number of selected component (if applicable):
php-pecl-apcu-4.0.10

How reproducible:
Install a package that depends on php-pecl-apc with EPEL enabled. After installation you will see php-pecl-apcu installed instead, offering no opcode caching

Steps to Reproduce:
1. Install + Enable EPEL
2. Install package depending on php-pecl-apc
3. Verify after installation that php-pecl-apcu is installed instead

Actual results:
php-pecl-apcu is installed for "Requires php-pecl-apc"


Expected results:
php-pecl-apc is installed for "Requires php-pecl-apc"

Additional info:

Comment 1 Remi Collet 2016-01-28 15:59:02 UTC
Packages should only requires "apc" when they use the apc API, which is provided by apcu (or apcu-bc for newer version).

Comment 2 Remi Collet 2016-01-28 16:15:14 UTC
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.

Comment 3 David 2016-01-28 16:29:03 UTC
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.

Comment 4 Remi Collet 2016-01-28 16:41:13 UTC
Of course, I mean

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

Comment 5 Remi Collet 2016-01-28 17:10:38 UTC
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).

Comment 6 David 2016-01-28 17:13:47 UTC
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

Comment 7 Carl George 2016-01-29 16:46:36 UTC
> 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"
]

Comment 8 Fedora Update System 2016-05-04 15:09:14 UTC
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

Comment 9 Fedora Update System 2016-05-04 15:09:19 UTC
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

Comment 10 Fedora Update System 2016-05-05 21:18:44 UTC
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

Comment 11 Carl George 2016-05-06 16:51:57 UTC
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

Comment 12 Remi Collet 2016-05-11 12:09:20 UTC
@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.

Comment 13 Fedora Update System 2016-05-21 05:19:23 UTC
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.