Bug 1691688

Summary: php-mysql no longer included
Product: Red Hat Enterprise Linux 8 Reporter: Morgan Weetman <mweetman>
Component: phpAssignee: Remi Collet <rcollet>
Status: CLOSED WONTFIX QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: unspecified Docs Contact: Lenka Špačková <lkuprova>
Priority: unspecified    
Version: 8.0CC: carl, fedora, jorton, pasik, rcollet, tbowling
Target Milestone: rc   
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Removed functionality
Doc Text:
The "mysql" extension previously available via the "php-mysql" package is no longer supported in PHP 7 in Red Hat Enterprise Linux 8. To use MySQL with PHP developers should use either the "mysqli" extension, or use MySQL via PDO extension, both of which are available in the "php-mysqlnd" package.
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-05-13 15:42:42 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:
Embargoed:

Description Morgan Weetman 2019-03-22 09:16:16 UTC
Description of problem:

php-mysql has disappeared/been replaced by php-mysqlnd

Please consider adding php-mysql as a 'provides' by php-mysqlnd

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

Comment 1 Remi Collet 2019-03-22 09:29:03 UTC
Soory, but seems a bad idea

With RHEL-7
php-mysql OR php-mysqlnd provides mysql, mysqli and pdo_mysql, so 3 extensions

With RHEL-8
php-mysqlnd provides mysqli and pdo_mysql, so only 2 extensions

The "mysql" extension doesn't exists anymore

We have a rule to provides php-foo for each provided extension
As we don'"t provide "mysql" extension, it doesn't make sense to add this provides


More, we have a packaging rule to require all used extensions (Fedora / EPEL)
So if a app really requires "mysql" extension (so php-mysql), it won't be usable with PHP 7+, so must not be installable

Comment 2 Morgan Weetman 2019-03-22 10:09:11 UTC
Would a meta package be acceptable? .. I'm thinking a lot of people will wonder where it went

Comment 3 Terry Bowling 2019-03-22 12:30:20 UTC
@Remi,

Thank you for the feedback.  So, are these incompatible?  Thinking about the user experience, whenever possible it is best if this types of changes can be auto migrated limiting the friction for users to move to a new release.  We have many initiatives underway to improve the user experience and reduce this type of technical debt that we force on users.

Does this require code changes in user php code in how they initialize and use the ND version?  If so, that obviously makes this much harder.  What is the scope and impact outside of the rpm packaging?

If a user manually installs this ND version, must they also make code or config changes elsewhere?


If this is limited to installing the proper package, I propose we do what we can to automate this.

If installing the ND version of the package requires code changes, we need to ensure this is documented and in the release notes that the old driver has been deprecated and dropped from RHEL 8 and guidance on how the user must transition.

This will be *significant* for the in-place upgrades as it potentially creates significant friction for a user to move from RHEL 7->8.

Comment 4 Remi Collet 2019-03-22 12:44:53 UTC
(In reply to Terry Bowling from comment #3)
> Does this require code changes in user php code in how they initialize and
> use the ND version?  If so, that obviously makes this much harder.  What is
> the scope and impact outside of the rpm packaging?

Yes, extensions have different API
mysql_* functions http://php.net/mysqli
mysqli_* functions http://php.net/manual/en/book.mysql.php

> If a user manually installs this ND version, must they also make code or
> config changes elsewhere?

So, indeed, old code using mysql extension need to be fully rewritten.

AFAIK, most applications have switch to mysqli or pdo_mysql long time ago.

> If this is limited to installing the proper package, I propose we do what we
> can to automate this.
> 
> If installing the ND version of the package requires code changes, we need
> to ensure this is documented and in the release notes that the old driver
> has been deprecated and dropped from RHEL 8 and guidance on how the user
> must transition.

This have rather been dropped from PHP 7
and was deprecated for years...