I'm trying to build a custom system with the ROOT env variable. eselect php does not seem to respect this variable. It does not list installed php versions and cannot set them. According to the wiki this should be supported: https://wiki.gentoo.org/wiki/Project:Eselect/User_guide#Advantages_for_end_users_and_system_administrators I didn't find any support in the code. I have attached my current fix/patch. It can list and set php modules but does not display the active version. I'm willing to work on it in case I get feedback or if this is a desired functionality. Reproducible: Always Steps to Reproduce: 1. ROOT=/var/mybuilroot/ USE="fpm" emerge php 2. ROOT=/var/mybuilroot/ eselect php list fpm 3. Actual Results: Cannot find a php installation. Actually already the post installation step of php fails. Expected Results: Should find the php installation
Created attachment 613582 [details, diff] root-env-patch My current patch to update the symlinks in to ROOT environment. This does not display the active php module.
This should work, but I've never tried it, so.... it probably doesn't. The PHP eselect module is actually configured with all of the right paths at build-time, using autotools: https://gitweb.gentoo.org/proj/eselect-php.git/ So if you have ROOT=/var/mybuilroot and if you install eselect-php (this should happen when you install PHP itself), then the copy of eselect-php that you get under /var/mybuilroot *should* look in the correct location. In other words, you should have two copies of "eselect php", 1. the system one in /usr/share/eselect/modules/php.eselect 2. the ROOTed one in /var/mybuilroot/usr/share/eselect/modules/php.eselect The first one should control the system copy of PHP, and the second one should control the copy of PHP in /var/mybuilroot. Does anything resembling the correct behavior happen if you run $ /var/mybuilroot/usr/bin/eselect php instead of just "eselect php"?
Hi Michal, thanks for the fast response. Yes I have seen that it's set a build-time. > In other words, you should have two copies of "eselect php", Yes, there are two installations in my setup. Both modules contain "/usr/lib64/" and I think this is correct. As the system under "/var/build-root" is supposed to later run on it's own this will be the correct path in that environment. During the build of this environment the executables from the "host" are used. So I have no influence what is executed in the post installation step of the php package. It will be /usr/bin/eselect. I have tried to execute /var/build-root/usr/bin/eselect manually, but without luck as it contains the same @LIBDIR@ path as the the one in the host. I think that has to be solved dynamically in the eselect module of the host environment. ideally the path has to created relatively so it could be checked if it links to the correct files.
(In reply to Stefan Langenmaier from comment #3) > > > In other words, you should have two copies of "eselect php", > > Yes, there are two installations in my setup. Both modules contain > "/usr/lib64/" and I think this is correct. As the system under > "/var/build-root" is supposed to later run on it's own this will be the > correct path in that environment. Upon closer inspection, you are right. Does everything work with the patch you provided? I think we should strip the trailing slash with ${ROOT%/} everywhere, but other than that it looks OK to me.
The installation has worked so far for me, but I'll report back on the functionality and with an updated patch next week.
Created attachment 616552 [details, diff] patch to respect the ROOT env variable This patch includes the trimming of the trailing slash and a warning if the module is used to display the configuration. The patch is working for me.
Thanks. I played with it for a bit to see if it was possible to get the list/show actions working. I think you just forgot to add ROOT in one place, - local link_target_dir="@LIBDIR@/${target}/bin" + local link_target_dir="${ROOT%/}@LIBDIR@/${target}/bin" unless there's a reason why that instance was left alone?
Hi Michael, this was intentional if I understand the `set_sapi` function correctly. https://gitweb.gentoo.org/proj/eselect-php.git/tree/src/php.eselect.in.in#n461 There, the symlinks are created while we are in the "host" environment. The symlinks have to be created to work later in the environment of the "ROOT" variable. So inside the "ROOT" environment if the link is still prefixed with the "ROOT" variable it will not work. While we are in the "host" environment the link actually points to the wrong binaries, but it should not be executed there. I hope this explains my understanding.
(In reply to Stefan Langenmaier from comment #8) > Hi Michael, > > this was intentional if I understand the `set_sapi` function correctly. > > https://gitweb.gentoo.org/proj/eselect-php.git/tree/src/php.eselect.in. > in#n461 > > There, the symlinks are created while we are in the "host" environment. The > symlinks have to be created to work later in the environment of the "ROOT" > variable. > > So inside the "ROOT" environment if the link is still prefixed with the > "ROOT" variable it will not work. > > While we are in the "host" environment the link actually points to the wrong > binaries, but it should not be executed there. > > I hope this explains my understanding. Ahhh I see. You need to be able to chroot() into the ROOT and have the symlinks still work. But for the list/show actions... if the symlinks are absolute and *not* prefixed with ROOT, then the symlinks inside the ROOT point outside of it and won't work before you chroot(). Maybe this can all be fixed by using relative symlinks. I'll think about it.
Created attachment 616630 [details, diff] relative-links.patch Can you try this? It seems to do the right thing in my made-up test scenario.
That applies on top of your patch, BTW.
(In reply to Michael Orlitzky from comment #10) > Created attachment 616630 [details, diff] [details, diff] > relative-links.patch > > Can you try this? It seems to do the right thing in my made-up test scenario. Cool, I just tried it and it's working for me. I can set the options and display them. > Ahhh I see. You need to be able to chroot() into the ROOT and have the symlinks still work. Yes, actually I'm trying to create the filesystem that I later want to use as Docker image.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/eselect-php.git/commit/?id=eccdef0c3d501060838c803ffa81ed79ca614dc0 commit eccdef0c3d501060838c803ffa81ed79ca614dc0 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2020-02-29 21:53:38 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2020-02-29 22:00:28 +0000 src/php.eselect.in.in: create symlinks relatively. As part of our $ROOT support, we need symlinks within $ROOT to point to stuff within $ROOT. The problem with that is that, if we create those symlinks with absolute paths, then you can't later chroot() into $ROOT and use them, because they'll point to the wrong place -- an absolute path that was only correct before you chrooted. Using relative symlinks seems to fix the problem, and shouldn't hurt anything in the common case where ROOT is unset or contains only a trailing slash. Thanks are due to Stefan Langenmaier for reporting the problem and helping us test the solution. Bug: https://bugs.gentoo.org/709422 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> src/php.eselect.in.in | 23 ++++++++++------------- 1 file changed, 10 insertions(+), 13 deletions(-)
Thanks, I committed your patch and made the symlinks relative. There's one other thing to do and then I'll make a new release.
(In reply to Michael Orlitzky from comment #14) > Thanks, I committed your patch and made the symlinks relative. There's one > other thing to do and then I'll make a new release. Thanks for your feedback and all the work!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=80e9cccfa6bf0f6fc15dda9f1423d5cdca8b2354 commit 80e9cccfa6bf0f6fc15dda9f1423d5cdca8b2354 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2020-03-01 13:10:27 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2020-03-01 13:58:34 +0000 app-eselect/eselect-php: new version 0.9.6. New EAPI=7 version with some nice stuff: * The php-fpm-launcher script and php-fpm.conf tmpfiles.d entry are now upstream, simplifying the ebuild. * We install a logrotate script for php-fpm. * The eselect module itself now supports $ROOT. * We support symlinks for the "phar" executable. Closes: https://bugs.gentoo.org/692194 Closes: https://bugs.gentoo.org/709422 Closes: https://bugs.gentoo.org/707876 Package-Manager: Portage-2.3.84, Repoman-2.3.20 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> app-eselect/eselect-php/Manifest | 1 + app-eselect/eselect-php/eselect-php-0.9.6.ebuild | 33 ++++++++++++++++++++++++ 2 files changed, 34 insertions(+)
