I asked for php litespeed support in bug #908876 because I want to incorporate an openlitespeed server into guru, but it was pointed out that I need this support first. If possible, please add support for this. openlitespeed uses the lsphp command to run php, not the normal php command. Reproducible: Always
Maybe a good first step would be to get OpenLiteSpeed into GURU *without* php or eselect-php support at first. When someone sits down to work on php or eselect-php it will be a big help if they can emerge openlitespeed from GURU and use it to test.
Thank you very much. I am currently trying to get openlitespeed into guru. Fortunately, openlitespeed contains php5 inside, so I should be able to use it for "debugging purposes". (php5 is no longer supported and cannot be used for production purposes). I am currently trying it out, and it should probably work until I get it into GURU and make it work. However, since openlitespeed depends on lsquic and lsquic depends on boringssl, it may be difficult to officially get openlitespeed from guru to gentoo. (There was a previous attempt to incorporate boringssl into gentoo, but it was rejected.)
Created attachment 892321 [details] openlitespeed ebuild and dependencies https://github.com/gentoo/guru/commit/7c9c9aa0513ac610b7725cc472cdef5e6dcc5d73 This was pointed out in the above commit, so I will upload it here. Please let me know if there is a proper way to process this ebuild.
Created attachment 892324 [details] openlitespeed ebuild and dependencies
Created attachment 892325 [details] openlitespeed ebuild and dependencies
If you use the latest attached ebuild, you can get openlitespeed to start the server manually. (There is a lack of automatic startup using systemd or openrc.) How should I handle this case? Since the included php is based on 5, it is most likely not appropriate to add it to guru as is.
(In reply to trakrailysurely from comment #6) > If you use the latest attached ebuild, you can get openlitespeed to start > the server manually. > (There is a lack of automatic startup using systemd or openrc.) > How should I handle this case? You'll have to write service scripts for both init systems. OpenRC uses what is basically a shell script with some extra features. There's a guide here, https://github.com/OpenRC/openrc/blob/master/service-script-guide.md and you can get pretty far by copying from the existing scripts in /etc/init.d. For systemd, the docs are at https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html Again, you can get off to a good start by copying an existing service file and changing some of the names and paths. Once you've written the scripts, the best thing to do would be to submit them upstream (to OLS), but in the meantime you can install them with "doinitd" (built in) or "systemd_dounit" (from systemd.eclass) in your ebuild. > Since the included php is based on 5, it is most likely not appropriate to > add it to guru as is. Yeah, you'll have to try to remove the default one and replace it with the system copy of PHP somehow. There are many known security vulnerabilities in even slightly-old versions of PHP. You've picked a very hard package to start with :)
Service scripts can be added. As for php, until bug #908876 is resolved, you cannot use php in the system. To get openlitespeed into guru in its current state, we need to build and integrate php8 inside the package, which is a rather useless task. Because after litespeed support is added to the system, it has to be removed. Is there a good way to help solve bug #908876 #908876?
(In reply to trakrailysurely from comment #8) > Service scripts can be added. > As for php, until bug #908876 is resolved, you cannot use php in the system. > > To get openlitespeed into guru in its current state, we need to build and > integrate php8 inside the package, which is a rather useless task. Because > after litespeed support is added to the system, it has to be removed. > Is there a good way to help solve bug #908876 #908876? Honestly, there isn't. You need three big things to happen all at once and someone to maintain them indefinitely. I'm the only person working on dev-lang/php right now and I don't have the time to do it. Even if you did all of the work yourself and submitted PRs, reviewing them would take at least as much time. I think you need a dedicated Gentoo developer who is interested in this.
