| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
PHP supports installing a "phar" executable that can archive/extract
the phar file format without the user having to learn the API and
write a little script. This commit allows "eselect php ... cli" to
manage a symlink to the "phar" command, so that when dev-lang/php
starts installing them, we can switch between the various versions.
Bug: https://bugs.gentoo.org/707876
Signed-off-by: Michael Orlitzky <mjo@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
While it didn't appear to hurt anything, the find_targets() function
could output a literal "php*.*" when there were no valid PHP targets.
Now the "nullglob" shell option is enabled during that function.
Signed-off-by: Michael Orlitzky <mjo@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michael Orlitzky <mjo@gentoo.org>
|
|
|
|
|
|
| |
The comments told me to remove this code after a while. I trust myself.
Signed-off-by: Michael Orlitzky <mjo@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When performing an out-of-source build (in particular, with "make
distcheck"), the rules that we were using to replace @LIBDIR@ and
friends were failing. Automake does a lot of path magic in its rules,
but not within the shell commands themselves, so ultimately we wound
up with some confusion between the source and build directories.
Rather than hack around this problem in the top-level Makefile.am,
I've converted the project to a recursive build, where the top-level
Makefile.am delegates to Makefile.am in the subdirectories. This
over-complicates things, but does fix the out-of-source build. Why?
A guess: because the path magic works better in "." than elsewhere.
Signed-off-by: Michael Orlitzky <mjo@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Since all of the log files for php-fpm wind up in the same place
regardless of slot, we install a single logrotate file as part of
eselect-php. The contents of the file may not be perfect -- they were
taken from the example submitted on bug 692194 untested -- but will be
easy to update in the future.
Bug: https://bugs.gentoo.org/692194
Signed-off-by: Michael Orlitzky <mjo@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
The tmpfiles.d entry for php-fpm creates one "runstate" directory for
all slots of php-fpm. Since none of that depends on the currently
selected slot, we ship it as part of eselect-php rather than
dev-lang/php which would either install one copy for each slot.
Signed-off-by: Michael Orlitzky <mjo@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While OpenRC services are powerful enough to compute the selected
version of php-fpm, the corresponding systemd services are not and
must use a fixed path. The executable at that fixed path must
therefore decide which version of php-fpm to run before running it.
This commit adds a script to do just that.
This script is already present in the app-eselect/eselect-php
package, tacked on from $FILESDIR. It's a better fit as part of
the repository.
Signed-off-by: Michael Orlitzky <mjo@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On FreeBSD, we're getting an error:
ln: illegal option -- -
usage: ln [-s [-F] | -L | -P] [-f | -i] [-hnv] source_file [target_file]
...
!!! Error: failed to create active php symlink
This is due to our use of the "--force" flag, which is not POSIX. In
the latest standard (IEEE Std 1003.1-2017), only the short "-f" flag
is guaranteed to exist, and FreeBSD's "ln" seems to mostly support the
flag as specified there. So, I've changed "--force" to "-f", and left
a warning to future generations in a nearby comment.
Bug: https://bugs.gentoo.org/649270
|
|
|
|
|
|
|
| |
When the apache conf file was being written in do_set(), it was
avoidable by e.g. update_sapi(). That could prevent apache2 from
restarting. Since do_set() calls set_sapi() anyway, we just move
the conf file writing to the end of set_sapi().
|
|
|
|
|
|
| |
These two inherit commands are no longer needed. We don't use
list_libdirs() anymore thanks to autotools, and I don't think the
config functions were ever needed recently.
|
|
|
|
|
| |
The name "list-modules" was always more appropriate; it just took a
moment to realize that "-" is valid in bash function names.
|
| |
|
|
|
|
| |
Gentoo-Bug: 491866
|
| |
|
|
|
|
|
|
|
|
| |
The update_sapi() function was not working due to a call to set_$sapi
that was never caught. Some of the logic in both do_update() and
update_sapi() was clarified, and the update_sapi() function was
documented. The "update" action and "cleanup" (which uses it) now work
as expected.
|
| |
|
| |
|
|
|
|
|
|
|
| |
The cleanup_sapis() function was only called in one place, so it was a
pointless layer of indirection. Move it into do_cleanup(). Also, make
sure we don't remove libphp[57].so symlinks unless they're actually
symlinks and in fact dead.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The last few commits introduced a problem: by passing
php.eselect.in.in through autoconf, we unwittingly replace things like
@bindir@ with ${exec_prefix}. This is because lowercase @bindir@
gets defined for automake and is intended to be based on the other
directory variables like @exec_prefix@. Since we're replacing them
after the fact in the Makefile, this commit avoids the autoconf
mangling by making them all uppercase.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The get_libdirs() function is a heuristic to determine which libdirs
are available on the system. The get_active_libdir() function then
chose the first one as the "active" libdir. In a few places we either
chose the "active" libdir, or looped through all of them to find some
other thing of interest (like the valid targets).
Now that we compute @libdir@ at build time, we can replace all of that
with the one correct value of @libdir@. The functions get_libdirs()
and get_active_libdir() are removed entirely.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are currently shipping 70_mod_php.conf as part of the Gentoo ebuild
for eselect-php. This introduces a potential disconnect between the
path in php.eselect and the path in 70_mod_php.conf. By adding the
conf file to the project, we are able to ensure that they are both
set to the same value. Moreover, the new autotools directory magic
lets us set them both based on @localstatedir@. So, for example, in
the conf file we have "@localstatedir@/lib/eselect-php/mod_php.conf"
and in php.eselect we have "@localstatedir@/lib/eselect-php".
We have followed the PHP project's lead in assuming that
$localstatedir will be set to (for example) /var and not /var/lib.
See Gentoo bug 572002. For testing, you should now use something like,
./configure --bindir=/usr/bin --sysconfdir=/etc --localstatedir=/var
Of course, the ebuild for eselect-php will automatically pass the
correct values to ./configure.
|
|
|
|
|
|
|
|
|
| |
As a first test of the new directory substitution, replace one
instance of custom bindir handling. Use @bindir@ instead of
"${EROOT}/usr/bin" sapi_active_link_dir(). The results should
coincide when configured with,
./configure --bindir="${EROOT}"/usr/bin
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we create php.eselect from php.eselect.in using autoconf, we
don't have a way to get the full, expanded value of @bindir@,
@libdir@, and the other paths that we need. The autoconf documentation
suggests a workaround for this: add another layer of indirection, and
use the Makefile to substitute those values into the output files.
This commit sets the stage by renaming php.eselect.in to
php.eselect.in.in. The first round of processing by autoconf takes
php.eselect.in.in to php.eselect.in. The Makefile will then generate
php.eselect from php.eselect.in after substituting @bindir@, @libdir@,
and @localstatedir@.
|
|
|
|
|
|
|
|
|
| |
The cleanup() action is supposed to remove the old links to libphp5.so
and libphp7.so, but the pattern was accidentally quoted and thus
nothing was removed. Unquote it so that those symlinks will actually
be removed.
Gentoo-Bug: 572436
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
There was a special case in set_sapi() for apache2's mod_php.so. Now
that has been factored out into a new function sapi_link_name_target()
which acts more or less like a hash table (dictionary lookup).
|
|
|
|
|
|
|
| |
With a little bit of mangling and a new (trivial) function, the
set_sapi() function now does the work of set_apache2(). There is
probably a better "big picture" to handle the symlinking, but this
works for now and is an improvement.
|
| |
|
| |
|
|
|
|
|
|
|
| |
The set_sapi() function was accidentally introduced in commit 91160d1
but was not used until now. This commit finishes its implementation,
and refactors the "easy" SAPI set_* functions to use set_sapi(). The
set_apache2() function still requires more work.
|
| |
|
|
|
|
|
|
|
| |
In preparation for refactoting the set_foo() functions, refactor the
function that gets the (one) active link path into two functions that
get the (one) active link directory and (more than one, potentially)
active link names.
|
| |
|
|
|
|
|
| |
The first parameter to resolv_target should be the name of a SAPI. The
current call passes "phpdbg" which is incorrect. Change it to "dbg".
|
|
|
|
|
|
| |
The resolv_target() function was making a call to find_targets_$1.
This was incorrectly refacored to "find_targets $1" instead of
"find_sapi_targets $1" and has been fixed.
|
|
|
|
|
|
| |
This follows in the same vein as the other recent refactorings. With
the machinery in place, list_cli, list_cgi, etc. are all replaced by
one function list_sapi() taking a SAPI name as an argument.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new function find_sapi_targets() takes a SAPI name as an argument
and outputs the valid targets for that SAPI. With it we replace the
following five functions that all did more or less the same thing:
1. find_targets_apache2()
2. find_targets_cli()
3. find_targets_fpm()
4. find_targets_cgi()
5. find_targets_phpdbg()
|
| |
|
|
|
|
|
| |
The documentation for the get_sapi_active_target() was copy/pasted and
never updated. Whoops. It's been fixed.
|