Re: upgrade glitches with php, maybe

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

> Date: Fri, 28 Mar 2025 09:04:59 -0400
> From: Greg Troxel <gdt%lexort.com@localhost>
> 
> I just had another thought, which is that this discussion is framed in
> terms of "something changed in pkgsrc and 'pkgin ug' does not handle it
> seamlessly, so that's not ok".

Something changed in pkgsrc breaking compatibility with _all_ PHP
packages, and _nothing_ handles it seamlessly because the only
mechanism we have come up with, after days of arguing, for rectifying
this self-inflicted breakage is yelling at users.

I think I would qualify as an exceptionally attentive and engaged user
of pkgsrc who is more willing than the vast majority of potential
users on the planet to invest personal time and effort into dealing
with fixing bullshit.  This approach drives me to just use Debian on
my servers.

> pkgin is not part of core pkgsrc.  The sources come from an upstream,
> stored on github, and change control in pkgin is not overseen by
> pmc/TNF.  (I'm not claiming in the slightest that there are bad changes
> or that there is anything wrong with how pkgin is maintained; I'm
> pointing out the structural situation.)

This is a historical accident of how pkgin grew, not a conscious
decision of governance.  (But it may become a conscious decision of
governance if we insist on treating pkgin as a second-class loser.)

> There has never been an expectation that pkg_add/pkgin can deal with
> upstream config changes.

The php config change here is purely self-inflicted by pkgsrc and has
nothing to do with upstream changes.

>                           There has never been an expectation that
> pkg_add/pkgin seamlessly handles package renaming.

We have had SUPERSEDES since 2009 to handle this.

If there's no expectation that the binary package tools can handle it,
that's because we have set expectations so low they're practically six
feet under.

> The PHP multiversion change was proposed, discussed, available for
> testing for along period, and then went in.  It's not a driveby cowboy
> update the day before the freeze.  (Again, not saying that should 100%
> determine anything, but I think it's important to look at the context.)

That is true -- and taca@ clearly put a lot of good effort into making
the multiversion packages work smoothly in new installations.

But all the proposal, discussion, and availability _in the development
tree_ appears to have missed critical details for _users_ who don't
track tech-pkg@ and pkgsrc-changes@ -- and who do just follow the
instructions in documentation to pkg_add or pkgin install binary
packages.

--- lang/php/phpversion.mk
+++ lang/php/phpversion.mk
@@ -218,7 +218,21 @@
 
 PHP_EXTENSION_DIR=	${PHP_LIBDIR}/${MACHINE_GNU_ARCH}
 
+.if ${PHP_MULTIVERSION_CONFIG:U:tl} == "yes"
 PKG_SYSCONFSUBDIR?=	php/${PHP_API_VERS}
+MAKE_ENV+=		PHP_MULTIVER=${PHP_VER}
+MAKEFLAGS+=		PHP_MULTIVER=${PHP_VER}
+FILES_SUBST+=		PHP_MULTIVER=${PHP_VER}
+MESSAGE_SUBST+=		PHP_MULTIVER=${PHP_VER}
+PLIST_SUBST+=		PHP_MULTIVER=${PHP_VER}
+.else
+FILES_SUBST+=		PHP_MULTIVER=
+MAKE_ENV+=		PHP_MULTIVER=
+MAKEFLAGS+=		PHP_MULTIVER=
+FILES_SUBST+=		PHP_MULTIVER=
+MESSAGE_SUBST+=		PHP_MULTIVER=
+PLIST_SUBST+=		PHP_MULTIVER=
+.endif
 
 MAKE_ENV+=		PHP_VERSION_REQD="${PHP_VER}" \
 			PHP_VER="${PHP_VER}" PHP_API_VERS="${PHP_API_VERS}" \