Summary: | Upgrading php slot breaks /usr/lib64/apache2/modules/libphp5.so symlink after removing the old slot | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sergey S. Starikoff <Ikonta> |
Component: | Current packages | Assignee: | PHP Bugs <php-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | xmw |
Priority: | Normal | ||
Version: | 10.0 | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=572436 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Sergey S. Starikoff
2012-08-27 12:09:00 UTC
Are you sure you installed both with apache2 USE flag? eselect php should be able to fix the symlinks. (In reply to comment #1) > Are you sure you installed both with apache2 USE flag? Yes, I'm sure. apache2 USE flag was turned on and wasn't changed. > eselect php should be able to fix the symlinks. Because my world list contains not slotted, but general dev-lang/php (so, after installation php-5.4 previous version php-5.3 is uninstalled) symlink is to be updated after installation of php-5.4. (In reply to comment #2) > (In reply to comment #1) > > eselect php should be able to fix the symlinks. > Because my world list contains not slotted, but general dev-lang/php (so, > after installation php-5.4 previous version php-5.3 is uninstalled) symlink > is to be updated after installation of php-5.4. So you unmerged php:5.3 or ran --depclean? There is no magic that considers if you installed php or php:slot. You need to take care of your symlinks using eselect just like with any other similar package. Automagically fixing the symlinks is also not the way to go since it would change config without the user explicitly asking for it. What I could do is add a warning that the unmerge breaks the symlink, but I would not put a high pri on such a feature. (In reply to comment #3) > What I could do is add a warning that the unmerge breaks the symlink, but I > would not put a high pri on such a feature. Adding some warning to elog message about broken symlink on unmerge looks to be a solution. (In reply to comment #4) > (In reply to comment #3) > > What I could do is add a warning that the unmerge breaks the symlink, but I > > would not put a high pri on such a feature. > > Adding some warning to elog message about broken symlink on unmerge looks to > be a solution. Committed a revbump that should warn about these issues. (In reply to comment #5) > Committed a revbump that should warn about these issues. I've thought for a time. It's just workaround and not a good solution. I've reproduced issue. Start point: # grep "dev-lang/php" /var/lib/portage/world dev-lang/php # eselect php list apache2 [1] php5.3 * [2] php5.4 Note active version of php. Action: emerge --depclean ... >>> These are the packages that would be unmerged: dev-lang/php selected: 5.3.15 protected: none omitted: 5.4.6 Done so. Result: # eselect php list apache2 [1] php5.4 No active php-interpreter apache2 module. php now is is broken. To my mind correct solution of this issue is to add --depclean checking about deleteing of active versions of eselect-managed applications. Similiarly like it is done for dev-lang/python (some time after stabilization of 3.2 slot I've used 3.1 as active one, emerge --depclean find it as omitted and not protected, but it wasn't ordered for uninstall because of result of additional check (matching value on result of eselect python list)). Correct portage's behaviour is to skip uninstalling of active verisions of applications (in case of reported issue prior to uninstalling of php:5.3 by --depclean user must switch on new version of php interpreter). (In reply to comment #6) > (In reply to comment #5) > > Committed a revbump that should warn about these issues. > I've thought for a time. > It's just workaround and not a good solution. > > I've reproduced issue. > > No active php-interpreter apache2 module. > php now is is broken. > Well. In my opinion, you broke it. You should really know that php 5.3 is still active and during the depclean list review, you should spot that it is about to be removed. And you can also avoid this problem by adding the 5.3 slot to @world > To my mind correct solution of this issue is to add --depclean checking > about deleteing of active versions of eselect-managed applications. > Similiarly like it is done for dev-lang/python (some time after > stabilization of 3.2 slot I've used 3.1 as active one, emerge --depclean > find it as omitted and not protected, but it wasn't ordered for uninstall > because of result of additional check (matching value on result of eselect > python list)). > Have you seen actual code for this? Or are you assuming? Python is a bad example because Portage has checks explicitly for the current python interpreter [1] > Correct portage's behaviour is to skip uninstalling of active verisions of > applications (in case of reported issue prior to uninstalling of php:5.3 by > --depclean user must switch on new version of php interpreter). File a feature bug about this to the Portage guys. [1] http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob;f=pym/_emerge/unmerge.py;h=b46b89cb8bcaea57f756c192ee36d6fce077e64e;hb=HEAD#l331 This is not fixed. workaround: eselect php cleanup I've just suffered this today for upgrading php5.4 -> php5.5 and running a depclean. Apache2 failed with the symlink /usr/lib64/apache2/modules/libphp5.so pointing to a no longer existing /usr/lib64/php5.4/apache2/libphp5.so The dumb fix was to correct the symlink. "depclean" did the right thing in removing the old php5.4. Without any user intervention: eselect php list apache2 [1] php5.5 * So... The symlink is overlooked?... Regards, Martin This should be fixed in the latest 5.6 and 7.0 ebuilds: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ef0386227889557b516d86fd395417b20aa5c4a1 Now, when you depclean the old slot, we run `eselect php cleanup` in its pkg_postrm() phase. That notices that the old symlink is dead and will attempt to "upgrade" the symlink to a working slot. |