Re: upgrade glitches with php, maybe

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

maya%NetBSD.org@localhost writes:

> I'll admit I'm not super familiar with the life cycle of config files...
> but, I wonder whether the renaming of the PHP packages could be avoided,
> so we won't have to use SUPERSEDES, avoiding this issue.

It can't really be avoided.

Before, we had php-8.1.x, php-8.2.x, php-8.3.x built from lang/php81,
lang/php82, lang/php83 (plus more versions).

Now we have php81-8.1.x, php82-8.2.x, php83-8.3.x.  And, they can be
installed at the same time.

I suppose you can say "can't php82- be php-" for now, so people using
the default aren't affected, but that just kicks the can down the road
at the expense of considerable semantic confusion.

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


really, this has already happened to people tracking current.  We are
only talking about the branch.

In the announcement, I suggest after the first paragraph.

  New in this branch is that multiple versions of php can coexist, which
  required renaming them.  THE UPGRADE PROCEDURE REQUIRES MANUAL
  ATTENTION TO AVOID LOSING CUSTOMIZATION.  See the php section later in
  this announcement.

So after the "php multiversion" intro, add

  At least one user has reported that when using pkgin to update a
  system, the php.ini config file for php-8.2, which had been modified,
  was incorrectly removed.  This also happened to php-fpm.d/www.conf.
  Therefore, before upgrading, make an *extra backup* of $prefix/etc (in
  addition to the backups you are already routinely making), and extract
  the intended diffs to upstream form all php config files.  After
  upgrading, re-apply these diffs to the corresonding files, now in a
  php/x.y subdirectory.  (Even without incorrect deletion, manual
  re-application of diffs is still required.)

This work has to be done sooner or later, and I see no reason to delay.
Really, good sysadmin practice is to examine config files and keep the
diffs to upstream understood and minimal.  And of course to have more
backups than one turns out to need.


There is the question "should we have held this php reorg until we had
more automatic migration", but that ship has sailed.