Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#3395 - PHP extension directory moved

Attached to Project: Arch Linux
Opened by Brent Pitman (bpitman0001) - Thursday, 27 October 2005, 23:46 GMT
Last edited by arjan timmerman (blaasvis) - Wednesday, 02 November 2005, 10:08 GMT
Task Type Bug Report
Category Packages: Current
Status Closed
Assigned To dorphell (dorphell)
Architecture not specified
Severity High
Priority Normal
Reported Version 0.7 Wombat
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Was this on purpose?

; Directory in which the loadable ffxtensions (modules) reside.
extension_dir = "/usr/lib/php/extensions/no-debug-non-zts-20041030/"

After the upgrade, all mysql and gd functions are broken. Additional packages that install php extensions are now putting them in the wrong directory.

Can we get this moved back to /usr/lib/php? At a minimum, put it in a directory with a name that doesn't look like it could change at any time. If you are moving this permanently, then users need more a warning than the one we see everytime we upgrade - warning: extracting /etc/php.ini as /etc/php.ini.pacnew.
This task depends upon

Closed by  dorphell (dorphell)
Monday, 05 December 2005, 16:34 GMT
Reason for closing:  Fixed
Comment by Jan de Groot (JGC) - Friday, 28 October 2005, 06:47 GMT
This is on purpose yes. This location changes whenever PHP gets an API change that makes previous modules incompatible with the running PHP version.
Comment by Alexander Baldeck (kth5) - Friday, 25 November 2005, 15:32 GMT
problem here is though that everytime a php upgrade comes around, nothing reminds me that api changes have been implemented which make it necessary to modify my php.ini.
Comment by Woody Gilk (Shadowhand) - Wednesday, 30 November 2005, 21:37 GMT
I have to point out that this is a horrible solution because it means that php.ini will be overwritten with EVERY upgrade of php. That seems unacceptable to me. Would it be possible to write a good post_upgrade that could sed the pre-upgrade php.ini and change what's necessary?

It just seems that forcing the user to edit php.ini after every upgrade is, well, crap.

(I'm sorry if all this is a bit harsh, but I just spent the last hour trying to figure out why mysql wasn't working with php, only to find out it was because some obscure (to me) things in php.ini had changed.)
Comment by Jan de Groot (JGC) - Wednesday, 30 November 2005, 22:09 GMT
Running sed over the existing php.ini is the least thing we can do, and is actually what we should do on upgrades.
Comment by Brent Pitman (bpitman0001) - Thursday, 01 December 2005, 03:56 GMT
Please make sure that there is a warning when php.ini is altered, especially when the file was defined in pacman.conf with NoUpgrade.
Comment by Leonard Ritter (paniq) - Saturday, 03 December 2005, 11:58 GMT
heh... the current solution is unnerving as well... just fixed my php.ini after an upgrade. switching back to the pacsave version did not solve anything, as the path was wrong.

what about making a diff between the last released .ini and the new one, and applying that diff to the user .ini?
Comment by Leonard Ritter (paniq) - Saturday, 03 December 2005, 11:59 GMT
you could also just ln -s the php module dir, and reference the non-date-containing directory.
Comment by dorphell (dorphell) - Monday, 05 December 2005, 16:15 GMT
To follow up on what Brent said, modifying /etc/php.ini directly is not a good idea. I try to edit live files as little as possible and here we gain nothing by editing it on install time. You lose 3rd party modules either way, so I rather stick with a safe symlink. I'm just not too keen about modifying files automatically which the users heavily modify on their own (exception would be something like /etc/shells). As an admin, I hate it when system-config files change without my authorization, so I don't like this.

I'm going with the symlink idea. The dir will now be "/usr/lib/php/extensions/php/"
Comment by dorphell (dorphell) - Monday, 05 December 2005, 16:34 GMT
Okay this should be fixed now... remember to make the change to "/usr/lib/php/extensions/php/" which is in the offical php.ini

Loading...