FS#57068 - [php71] php-apcu API versions mismatch

Attached to Project: Community Packages
Opened by Denis Speranskiy (Speranskiy) - Friday, 12 January 2018, 11:01 GMT
Last edited by Sergej Pupykin (sergej) - Thursday, 15 March 2018, 12:24 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sergej Pupykin (sergej)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

With php71 php-apcu is not able to be used.
```
PHP Warning: PHP Startup: apcu: Unable to initialize module
Module compiled with module API=20170718
PHP compiled with module API=20160303
```
I suppose either php71 or php-apcu must be recompiled.
This task depends upon

Closed by  Sergej Pupykin (sergej)
Thursday, 15 March 2018, 12:24 GMT
Reason for closing:  Fixed
Additional comments about closing:  php71 removed
Comment by Eli Schwartz (eschwartz) - Friday, 12 January 2018, 13:48 GMT
  • Field changed: Attached to Project (Community Packages → Arch Linux)
  • Field changed: Summary ([php71] php71 php-apcu API versions mismatch → [php] php71 php-apcu API versions mismatch)
  • Field changed: Status (Unconfirmed → Assigned)
  • Task assigned to Pierre Schmitz (Pierre)
You cannot mix and match different versions of php!

Split packages that strictly depend on each other should probably do what e.g. the gcc package does and depend on $pkgbase=$pkgver-$pkrel
Comment by Jan de Groot (JGC) - Friday, 12 January 2018, 13:53 GMT
php-apcu is a 7.2 module, so it won't work with 7.1
Comment by Pierre Schmitz (Pierre) - Tuesday, 30 January 2018, 18:43 GMT
You should update to the latest version of PHP; keeping old versions is not supported.
Comment by Doug Newgard (Scimmia) - Tuesday, 30 January 2018, 18:55 GMT
Sorry, Pierre, but it is supported when we have "php71" packages in the repos
Comment by Pierre Schmitz (Pierre) - Tuesday, 30 January 2018, 19:05 GMT
I was not aware of such a package. I am not sure why such packages exists but they should use paths and configurations different from the regular PHP package.

I'll assign the php7.1 packager. Would also be nice to document why we package old versions; e.g. I am not aware of major incompatibilities between 7.1 and 7.2.
Comment by Eli Schwartz (eschwartz) - Tuesday, 30 January 2018, 19:12 GMT
Because of things like  FS#56553  and  FS#56628 
Comment by Pierre Schmitz (Pierre) - Tuesday, 30 January 2018, 19:17 GMT
It should be way easier to fix these arbitrary restrictions of those packages than trying to provide two different versions of PHP.

I know this wont help users but in these cases upstream is really to blame.
Comment by Sergej Pupykin (sergej) - Tuesday, 30 January 2018, 21:12 GMT
I guess that we will maintain php56, php71, php as well as we already do for ruby2.3, ruby2.4, and ruby :)

For example I still use php56 from aur because of updating many sites take too much time. It is easier to use php56 (it is supported until the end of 2018 so web developers have at least 11 months to update their sites).

Loading...