Re: upgrade glitches with php, maybe

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Thu, 27 Mar 2025 18:01:47 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
> 
> maya%NetBSD.org@localhost writes:
> 
> > That does leave what happens to someone who had the intermediate PHP
> > installed and made local changes to the config, and I'm not sure how it
> > should be best handled. It's certainly less people affected.
> 
> I think we should
> 
>   send a message just about this to netbsd-announce (and forward to
>   pkgsrc-users)
> 
>   be loud about it in the branch announcement, a quick comment really up
>   front, and a seciton in the end.

This is the same approach that led us to the pkgdb move catastrophe.

I think we should try to avoid repeating that.

It is hard to take pkgsrc as a platform seriously, particularly the
binary package repositories, when, instead of preparing and testing a
migration plan for a major change, we yell at users to just tough it
out.  Every time we do that we set fire to whatever credibility we
might have grown learning from the last time.

The status quo of the released binary packages is that php config goes
in (e.g.) /usr/pkg/etc/php.ini and /usr/pkg/etc/php-fpm.conf.  If we
preserve this status quo, at the cost of _not_ enabling php
multiversion installations just yet, we don't regress and we don't
_need_ a migration plan (other than the SUPERSEDES issue).

We could preserve it by making the the PHP PKG_SYSCONFSUBDIR setting a
default-off option, say PHP_MULTIVERSION_CONFIG=yes/no in mk.conf.
Users making their own custom packages who are willing to handle the
migration could _opt into_ this major change, but users who just
naively did

	pkgin install php82-fpm

on NetBSD don't get burned and treated as neglected second-class
users.

Later, if we formulate a migration plan, we might make that option
default-on or always-on and thereby enable php multiversion
installations by default out of the box.  But until then, it's not a
regression from the last quarterly branch if php multiversion
installations don't work.

That doesn't mean taca@'s huge effort to make php multiversion
installations work smoothly would be wasted -- it just means we take
our time at a leisurely pace, not in the crunch of a freeze, to plan
how to handle migrating config files before we break installations of
users who upgrade via binary packages.


(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.)