build .rpm and .deb packages to automatically install and configure frankenphp

[henderkes]

see #1459

requires fpm but it works perfectly well to automatically configure frankenphp

we could let this script run in the centos 7 container on deployment.

[henderkes]

even better, once crazywhalecc/static-php-cli#673 is merged, we can --build-shared=xdebug in the glibc command and automatically release frankenphp-xdebug-$(FRANKENPHP_VERSION) and frankenphp-ffi-$(FRANKENPHP_VERSION).

Still need to think about how to appropriately handle this in CI though, I'm not sure if FRANKENPHP_VERSION is automatically set as an environment variable, or if the build-static script sets it.

Could change the build-static script to export the version and call ./build-packages.sh after and modify the dockerfile to install ruby, fpm and rpm-build.

[henderkes]

now I'm getting a weird bug where the worker keeps counting $i up twice instead of once. Other than that, it's working well I think.

[henderkes]

success! to get them from the container after building we can run

docker run --rm static-builder-gnu sh -c "ls /go/src/app/dist | grep '^frankenphp'" | xargs -I {} sh -c 'docker cp $(docker create static-builder-gnu):/go/src/app/dist/{} ./{}'

[henderkes]

@dunglas I'm happy with this now. Prepared things for when we merge shared extension support into static-php-cli as well.

The reason I haven't added a .apk is that alpine doesn't even ship with an init system by default (OpenRC is only included in the full blown desktop version), so I felt it made no sense to write a package that adds no real benefits to a simple binary download.

[dunglas]

This is AWESOME.

I left some minor comments. I also think we should ensure that the experience is as similar as possible between the Docker images, the Brew package and the Linux packages (demo files, php.ini, Caddyfile etc) to simply the maintenance and support.

[dunglas]

That would be nice to use the same Caddyfile in every distributions, with the same features enabled.

[henderkes]

I don't think it makes sense to enable a worker by default in the docker Caddyfile. There's no example project (and it makes no sense to ship one either).

[dunglas]

Could we reduce or remove the provided demo files?
Could we also share them between the Docker images and the packages?

@ginifizz will take a look to the graphic design part.

[dunglas]

Could we reduce or remove the provided demo files?
Could we also share them between the Docker images and the packages?

@ginifizz will take a look to the graphic design part.

[henderkes]

Yes we could, but my reasoning behind spinning up this small example is that one of the major advantages has is the easy integration of worker mode. Simply using php_server could as well be replaced by php_fastcgi.

We could unify the index.php and example.php files into one, but it would make for a messy html + php blob. It also showcases the best practise of serving php with an entry point in a subfolder, rather than (potentially) exposing the whole project.

I'll leave this up to you to decide, I just thought simply serving a static html file was a bit pointless.

As for the docker images, I'll have to look how to add files to them.

[henderkes]

I had to switch to a frankenphp user, uninstalling frankenphp or caddy would automatically remove the other's user otherwise.

[henderkes]

I don't have the faintest idea how caddy works around not having to do this. Or maybe they do and I simply cannot find it in the install scripts.

[henderkes]

We've merged dynamic extension support into static-php-cli, by the way. Should I put that into this PR and also build a frankenphp-xdebug package that depends on the frankenphp package?

For that, I actually have a question - is it possible to load php with and without xdebug and route the request depending on whether a XDEBUG_SESSION header is set?

Right now I check for (pseudocode, can't check atm)

route {
    @xdebug header *XDEBUG_SESSION*
    php_fastcgi @xdebug /path/to/www.sock
    php
}

where php_fpm has xdebug loaded and frankenphp doesn't.

Edit: I think frankenphp-xdebug would be a thing for another PR. Let's get regular frankenphp packages merged first.

[dunglas]

This looks almost good to me, but I'm far from being a specialist of packaging.

We'll have to setup package repositories after that, right?

[dunglas]

Shouldn't we also copy php.ini-development? What php.ini are using the official packages by default? Maybe should we be in sync with their behaviors?

[henderkes]

What php.ini are using the official packages by default? Maybe should we be in sync with their behaviors?

Now here's the kicker, they don't ship the php.ini-production or php.ini-development but create the php.ini file that I initially committed into the package folder.

[dunglas]

Same here

[dunglas]

Do we really need to change the defaults? If so, we'll have to update the docs too

[henderkes]

The default for php is /etc/php.ini and /etc/php.d or /etc/php/conf.d depending on the distro. I doubt we wish to use those directories as we'd couple our frankenphp changes to those of the system php package. There are too many reasons why this is a terrible idea.

When compiling php without --with-config-file-path it chooses /usr/local/etc/php/php.ini and a different additional path depending on the system it was compiled on. That default is not in line with any system installation you would expect from a rpm/deb package. My only other idea for this was /etc/frankenphp.ini and /etc/frankenphp.d, but that would suggest frankenphp is something different than php, which it isn't.

[henderkes]

To expand on this, /usr/local/etc/ is the folder for user, not system installations of self-compiled software. FrankenPHP installed from a package should definitely not reside there - what if the user compiles and installs php themselves? Suddenly our frankenphp package is broken.

[henderkes]

This looks almost good to me, but I'm far from being a specialist of packaging.

We'll have to setup package repositories after that, right?

Not necessarily. dnf and apt can both install repositories directly from a url.

dnf install https://github.com/dunglas/frankenphp/releases/latest/frankenphp-1.5.1-1.rpm.

Alternatively we could follow caddy's approach on distros where other package repositories do not have a caddy package and create our own package registry. Then people would have to dnf install https://dunglas.dev/packages followed by dnf install frankenphp. I think the latter is outside the scope of this for now because it's not related to the creation of the packages.

[henderkes]

I've tried to unify the php paths from the docker images and the static binaries/system installations, but that throws up more problems than it solves. php from the docker images is inherently not built by us and uses all sorts of directories that are different from the ones we (should) use for the static versions.

[henderkes]

As for the default project installed into /usr/share/frankenphp, I'll leave this open to you. What files do you want installed? Do you want worker mode enabled by default?

I think it's easier if you make the changes yourself. You have push access to the branch of this pr.