Bug 1302785 - php-pecl-apcu claims to provide php-pecl-apc
Summary: php-pecl-apcu claims to provide php-pecl-apc
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: php-pecl-apcu
Version: el6
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Remi Collet
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-01-28 15:47 UTC by David
Modified: 2016-05-21 05:19 UTC (History)
2 users (show)

Fixed In Version: php-pecl-apcu-4.0.11-2.el6
Clone Of:
Environment:
Last Closed: 2016-05-21 05:19:25 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.