Re: upgrade glitches with php, maybe

[Greg Troxel <gdt%lexort.com@localhost>]

Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:

BLUF:

  I was confused about my old php.ini being removed; it wasn't.

  I had not modified php_fpm config.

  The default content of php_fpm.d/www.conf was changed in pkgsrc to use
  a unix domain socket instead of 127.0.0.1:9000, which is arguably a
  security fix.

> Two builds of the package read:
>
> -# FILE: etc/php-fpm.conf c share/examples/php/php-fpm.conf 0644
> ...
> +# FILE: etc/php/8.2/php-fpm.conf c share/examples/php/8.2/php-fpm.conf 0644
>
> So I think it is unlikely that a file called `php_fpm.conf' was
> touched.  However, it's possible you confused it with a file
> previously called /usr/pkg/etc/php-fpm.conf, and now (after the
> multiversion php change) called /usr/pkg/etc/php/8.2/php-fpm.conf.

I did expect new config file locations.  I went looking for my old
files, as I expected that any modified config files would remain.   I
was confused about php.ini, not seeing it in /usr/pkg/etc/php/php.ini,
where of course I realize now it never was.   So now I believe:

  when I ran "pkgin fug" (as you guessed below from my bad wording)

    /usr/pkg/etc/php.ini was left in place

    /usr/pkg/etc/php_fpm.conf and /usr/pkg/etc/php_fpm.d/www.conf were removed


Sorry for missing php.ini and having you go through that testing, but I
think it's at least useful that you have confirmed that the "don't
remove modified config files" logic appears correct.

> There are expected to be some differences in these files:
>
> --- a/share/examples/php/php-fpm.conf	2024-12-28 16:30:09.000000000 +0000
> +++ b/share/examples/php/8.2/php-fpm.conf	2025-03-15 12:57:02.000000000 +0000
> @@ -14,14 +14,14 @@
>  ; Pid file
>  ; Note: the default prefix is /var
>  ; Default Value: none
> -pid = run/php-fpm.pid
> +pid = run/php-fpm82.pid

Sure; that's why I said the normal sysadmin approach to any version
change is diff/merge, and to maintain minimal/intended diffs at all
times.

>>  2) ask if my belief that a user-modified config file should never be
>>  deleted by pkg_* and pkgin is shared by others and believed to be how
>>  it is.
>
> This belief is correct and such a deletion, if confirmed, should be
> treated as a severe regression that should hold up the branch.

I am not sure it's a regression and could be latent in the config file
handling.

> The existing logic in mk/pkginstall/deinstall that is pasted into
> php82-fpm-8.2.26nb11 deinstall script reads:
>
>         # Remove configuration files if they don't differ from the default
>         # config file.
>         #
>         ${TEST} ! -x ./+FILES ||
>                 ./+FILES REMOVE ${PKG_METADATA_DIR}
>
> This calls into the REMOVE logic in mk/pkginstall/files, with the
> following input embedded in the php82-fpm-8.2.26nb11 install script:

> AND
> (e) `${CMP} -s "$file" "$f_eg"` exits zero, i.e., the configuration
>     file $file is identical in content to the example $f_eg.
> AND
> (f) $f_flags contains `f' (here it does not), OR
>     $f_flags does not contain `r' and _PKG_CONFIG=yes, OR
>     $f_flags contains `r' and _PKG_CONFIG=yes and _PKG_RCD_SCRIPTS=yes.

So that should be ok; the CMP is the key point.

> You can verify whether or not your config file was modified by
> fetching the old package and extracting the example file, for now.  My
> guess is that you used this package:
>
> https://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/x86_64/10.0/All/php82-fpm-8.2.26nb11.tgz

No, I built it myself, after a php micro update in 2024Q4 (December),
but indeed it was good to check.  It turns out:

  my config file was not modified

  php-fpm package has changed the default from 127.0.0.1:9000 to
  unix:/var/run/php82-fpm

> This itself appears to be a problem: `pkgin in php82' had the effect
> of (upgrading some packages and) _deleting_ php82-fpm.  However, it
> left both /usr/pkg/etc/php-fpm.conf and /usr/pkg/etc/php/php_fpm.conf
> intact.

Interesting; I only dig "pkgin fug" (which I know is = "pkgin ug")

> Next, I tried `pkgin ug'.  It did not suggest replacing php-8.2.6 by
> php82-8.2.8:
>
> 	calculating dependencies...done.
> 	
> 	1 package to refresh:
> 	  pkgin-24.12.0
> 	
> 	2 packages to upgrade:
> 	  pkg_install-20250219 sqlite3-3.48.0
> 	
> 	0 to remove, 1 to refresh, 2 to upgrade, 0 to install
> 	0B to download, 194K of additional disk space will be used
> 	
> 	proceed ? [Y/n] n
>
> This is in spite of the fact that the pkg_summary.gz has
>
> 	PKGNAME=php82-8.2.28
> 	...
> 	SUPERSEDES=php-[0-9]*
>
> which strikes me as another problem: users who try to upgrade naively
> will get stuck with outdated PHP packages.

My binary packages only have php82-* because that's all I want this
minute, on this os/version/arch.   My upgrade actually went ok.

So my problems in the end turned out to be:

  I was confused and thought the old php.ini was gone.  Had I not been
  wrong about that I would have diffed/merged and carried forward two
  non-default lines (that don't seem to really matter anyway).

  I needed to change php_fpm=yes to php_fpm82=yes in rc.conf.

  The php_fpm listen socket default changed, and I needed to either
  adjust it back or adjust nginx forward.  *This problem has nothing to
  do with the php multiversion change.* (The default changed with the
  introduction of lang/php82/patches/patch-sapi_fpm_www.conf.in which
  changes the listen default from 127.0.0.1:9000 to a socket, and that
  was coincident in time with the multiversion change.  Arguably it's
  much better to use unix domain socket and not expose the fpm server
  to all local users.)