Updating to the latest release from PHP 5.2.*, leads to some old directories not being deleted: ls -l /etc/php/ total 16 --- drwxr-xr-x 3 root root 4096 Jan 12 18:24 apache2-php5 --- drwxr-xr-x 4 root root 4096 Jan 12 17:43 apache2-php5.3 --- drwxr-xr-x 3 root root 4096 Jan 12 17:44 cli-php5 --- drwxr-xr-x 4 root root 4096 Jan 12 17:43 cli-php5.3 tmarques@SiM /tmp $ equery l php [ Searching for package 'php' in all categories among: ] * installed packages [I--] [ ] app-admin/eselect-php-0.6.2 (0) [I--] [ ] dev-lang/php-5.3.5 (5.3) Reproducible: Always Expected Results: Only PHP 5.3 directories should exist.
What about config files in old directory? Was they changed? If answer is "yes", then they shouldn't be deleted.
No, and "equery b" doesn't return any package as the owner of those two directories. I stumbled upon this as I was trying to edit the old files while I didn't noticed the new ones.
After unmerging, equery can't know who is owner of files in dir /etc/php/apache2-php5/ . You should go back to php unslotted, paste equery k php , then do upgrade to php:5.2 (or :5.3) and tell if php.ini still exists.
I don't know exactly how equery works but I'm surprised that you say since PHP 5.3 didn't install to that directory AND uninstalled the previous unsloted 5.3 PHP, which did own them. So, my question is: if the owner package was uninstalled and the new one, previously installed, didn't touch those dirs, why hasn't the removal of the unslotted package removed it's dirs? This is on another server that still has unslotted 5.3 PHP: equery k php [ Checking dev-lang/php-5.3.3-r1 ] !!! /etc/php/apache2-php5/ext-active does not exist !!! /etc/php/cli-php5/ext-active does not exist * 332 out of 334 files good tmarques@theserver ~ $ equery b /etc/php/apache2-php5/php.ini [ Searching for file(s) /etc/php/apache2-php5/php.ini in *... ] dev-lang/php-5.3.3-r1 (/etc/php/apache2-php5/php.ini) I had a block with php-5.3.3-r1 and php-toolkit. I uninstalled it and the files which equery confirmed belonged to the package were still there. PHP-5.3.5 installed the new apache2-php5.3 and cli-php5.3 directories, as expected.
/etc/php is also the home of php extension configs. Having one of them installed will protect the dir from being unmerged. I'm curious: you don't edit your php.ini at all? Because, well, you're supposed to. At least to set the timezone. Going to reproduce this as soon as I can get my hands on my devbox :)
I know it is the home, it is not /etc/php that is the issue here. This version brought integration with eselect and it didn't clean the old /etc/php/(apache|cli)php5 dirs, which were replaced by numbered versions. It was because I was editing the files in /etc/php/apache2-php5 and not /etc/php/apache2/php5.3 that I noticed something was wrong. I'm setting the timezone in the application. I think that if you're going to have a global timezone set in php.ini perhaps it is best to have it be the same as defined in /etc/conf.d/clock, no? Best regards
Correct me if I am wrong here, but /etc/php/*5 is covered by CONFIG_PROTECT as it is a subdirectory of /etc That /etc/php/*5 is preserved is the intended behaviour. Extension ebuild remove the /symlink/ to extension configs though. This is to prevent php from trying to load modules that have been unmerged.
Going WONTFIX. I confirmed that unmerging at brand new install of php did remove the config files /etc/php/*php5.2/php.ini. However, it won't remove those if you got extensions installed. This will prevent portage from removing /etc/php/*php5/ext* I believe this is the correct behavior. Please inspect those left-over config files for changes you want to migrate and delete them manually afterwards. Yes, this is might lead to trouble. Yes, you need to be careful. But that's how the system works, currently. It even warns you about it, now. That said, I'll take this troubles into account when we get into such a situation again. Thanks.
You're right, there were some suhosin files in there. If it warns about that, it's enough to provide some sense of what's going on. Thanks!
