Re: upgrade glitches with php, maybe

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

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

> (All that said, I don't use PHP in pkgsrc.  So maybe I am out of line
> in claiming that a migration plan for this is important, and maybe
> just making the PKG_SYSCONFSUBDIR setting optional isn't an adequate
> workaround.  But it seems that the issues we're discussing here have
> already burned people in pkgsrc-current.)

I see your points, but a sysadmin doing migration is extracting the
intended diffs from php.ini, any modules (typically little to none), and
php_fpm, and applying those to the new location.  This is not desktop;
this is someone running a web appplication complicated enough to be
using fastcgi, and you need to be used to web server config to deal with
it in the first place.

In my case, the total number of changed lines (after my merge) was 3:
  php:
    bump memory limit
    bump opcache string buffer

  fpm:
    set gid for unix socket to match nginx

and of those only the last (replacing "listen on 127.0.0.1:9000") and
the corresponding config in nginx (non-deafult in either case) actually
caused a problem.

And, changing php_fpm=yes to php_fpm82=yes in rc.conf.

While a program failed to start (because of the rc.conf name change I
had been using 127.0.0.1:9000 for fpm, set in nginx.conf, and fpm
stopped doing that because of lost config), once I reconfigured
nginx/fpm to talk (I decided to use unix-domain sockets), everything
that fine.

There was no data loss, and there was no split-brain state that had to
be cleaned up.

When upgrading from php 8.1 to 8.2, one has to hand-merge the old diffs
into the new config, or else be running 8.2 with an 8.1 config file.
For any program that has the "set lots of things in config" style (which
I think is an upstream bug; config files should contain only non-default
content and default-installed config files should be empty), every
update requires a merge.  We have never had any support for that.

Beyond config files, when upgrading from one pgsql version to another,
eventually forced by the old one being removed, one has to pg_dump and
restore.

While it's not a structural regresssion, I think people are increasingly
running into "package A needs php <= X and B needs php >= Y (and X <
Y)", which for their usage is a regression when it happens as they have
to have 2 pkgsrc installs or a separate machine.  The php world is like
that; you can't just use newer on older code.

I'm not arguing that figuring out how to hold this a quarter is the
wrong approach.   Just that it's not at all like the pkgdb migration
(which I'm quite familiar with as I wrote the script to do migration).