Re: UPDATE: php revamp

[Stuart Henderson]

On 2017/11/12 00:02, Stuart Henderson wrote:
> Yep. Updated locally.

So. Any OKs or NAKs for this as a first step?

Index: Makefile.inc
===
RCS file: /cvs/ports/lang/php/Makefile.inc,v
retrieving revision 1.96
diff -u -p -r1.96 Makefile.inc
--- Makefile.inc24 Aug 2017 10:03:25 -  1.96
+++ Makefile.inc14 Nov 2017 11:33:24 -
@@ -8,7 +8,7 @@ COMMENT-fastcgi=stand-alone FastCGI ver
 PKGNAME-main?= php-${V}
 PKGNAME-fastcgi?=  php-fastcgi-${V}
 
-DISTFILES?=php-${V}.tar.bz2
+DISTFILES+=php-${V}.tar.bz2
 
 DISTNAME?= php-${V}
 CATEGORIES=lang www
@@ -20,7 +20,6 @@ MASTER_SITES= http://se.php.net/distrib
http://us.php.net/distributions/ \
http://no.php.net/distributions/ \
http://uk.php.net/distributions/
-MASTER_SITES0= https://download.suhosin.org/
 
 # UPGRADERS: please read BOTH the PHP and Zend licenses
 # and make sure they are safe before an upgrade
@@ -48,11 +47,6 @@ INI_TEMPLATES?=  development production
 # don't have.
 USE_LIBTOOL?=  No
 
-.if ${PV} != "7.0"
-FLAVORS=   no_suhosin
-.endif
-FLAVOR?=
-
 PATCHORIG= .orig.port
 CONFIGURE_STYLE=   autoconf
 AUTOCONF_VERSION?= 2.69
@@ -355,18 +349,6 @@ RUN_DEPENDS-main=  mail/femail,-chroot
 LIB_DEPENDS-fastcgi=   ${LIB_DEPENDS-main}
 RUN_DEPENDS-fastcgi=
 
-SUHOSIN_V= 0.9.38
-.if ${FLAVOR:Mno_suhosin} || ${PV} == "7.0"
-SUPDISTFILES=  suhosin-${SUHOSIN_V}.tar.gz:0
-.else
-DISTFILES+=suhosin-${SUHOSIN_V}.tar.gz:0
-PATCH_LIST=patch-* suhosin-*
-CONFIGURE_ARGS+=   --enable-suhosin
-
-pre-patch:
-   @mv ${WRKDIR}/suhosin-${SUHOSIN_V} ${WRKSRC}/ext/suhosin
-.endif
-
 pre-fake:
${INSTALL_DATA_DIR} ${PREFIX}/${APACHE_MODULE_SUBDIR}/modules
 
@@ -384,11 +366,7 @@ pre-configure:
 MODULE_NAME-${i}=  ${i}
 DESCR-${i}=${.CURDIR}/../files/DESCR-${i}
 PKGNAME-${i}=  php-${i}-${V}
-.if ${V:M5.4*}
-PKGSPEC-${i}=  php-${i}->=5.4,<5.5
-.elif ${V:M5.5*}
-PKGSPEC-${i}=  php-${i}->=5.5,<5.6
-.elif ${V:M5.6*}
+.if ${V:M5.6*}
 PKGSPEC-${i}=  php-${i}->=5.6,<5.7
 .elif ${V:M7.0*}
 PKGSPEC-${i}=  php-${i}->=7.0,<7.1
Index: php.port.mk
===
RCS file: /cvs/ports/lang/php/php.port.mk,v
retrieving revision 1.16
diff -u -p -r1.16 php.port.mk
--- php.port.mk 25 Apr 2017 11:26:43 -  1.16
+++ php.port.mk 14 Nov 2017 11:33:24 -
@@ -3,9 +3,7 @@
 CATEGORIES+=   lang/php
 
 MODPHP_VERSION?=   5.6
-.if ${MODPHP_VERSION} == 5.5
-MODPHP_VSPEC = >=${MODPHP_VERSION},<5.6
-.elif ${MODPHP_VERSION} == 5.6
+.if ${MODPHP_VERSION} == 5.6
 MODPHP_VSPEC = >=${MODPHP_VERSION},<5.7
 .elif ${MODPHP_VERSION} == 7.0
 MODPHP_VSPEC = >=${MODPHP_VERSION},<7.1
Index: 5.6/Makefile
===
RCS file: /cvs/ports/lang/php/5.6/Makefile,v
retrieving revision 1.51
diff -u -p -r1.51 Makefile
--- 5.6/Makefile24 Aug 2017 10:52:41 -  1.51
+++ 5.6/Makefile14 Nov 2017 11:33:24 -
@@ -5,6 +5,24 @@ BROKEN-alpha=  pcre_jit_compile.c:65:2: e
 PV=5.6
 V= ${PV}.31
 
-WANTLIB-main+= ${COMPILER_LIBCXX} ncurses readline
+MASTER_SITES0= https://download.suhosin.org/
+
+WANTLIB-main+= ${COMPILER_LIBCXX} ncurses readline
+
+FLAVORS=   no_suhosin
+FLAVOR?=
+
+SUHOSIN_V= 0.9.38
+
+SUPDISTFILES=  suhosin-${SUHOSIN_V}.tar.gz:0
+
+.if !${FLAVOR:Mno_suhosin}
+DISTFILES+=suhosin-${SUHOSIN_V}.tar.gz:0
+PATCH_LIST=patch-* suhosin-*
+CONFIGURE_ARGS+= --enable-suhosin
+
+pre-patch:
+   @mv ${WRKDIR}/suhosin-${SUHOSIN_V} ${WRKSRC}/ext/suhosin
+.endif
 
 .include 
Index: 7.0/distinfo
===
RCS file: /cvs/ports/lang/php/7.0/distinfo,v
retrieving revision 1.18
diff -u -p -r1.18 distinfo
--- 7.0/distinfo1 Sep 2017 08:25:02 -   1.18
+++ 7.0/distinfo14 Nov 2017 11:33:24 -
@@ -1,4 +1,2 @@
 SHA256 (php-7.0.23.tar.bz2) = b+lM78fSxg7iwWSLl3vu11atnNCn5OqLuM9SHZNVoJw=
-SHA256 (suhosin-0.9.38.tar.gz) = wC12xOfOd3kQo3wYGBy2f9npDv4BB/6rPeMTG1+JvOo=
 SIZE (php-7.0.23.tar.bz2) = 14630426
-SIZE (suhosin-0.9.38.tar.gz) = 122800

Re: UPDATE: php revamp

[Marc Espie]

On Sun, Nov 12, 2017 at 12:02:39AM +, Stuart Henderson wrote:
> Yep. Updated locally. Seems a bit odd to list in both SUPDISTFILES
> and DISTFILES but bsd.port.mk(5) says it's allowed.

That's precisely the kind of stuff it's meant to deal with.
When we introduced SUPDISTFILES, the idea was to make sure to
never miss a file for makesum.

So yep, SUPDISTFILES has all necessary files that may vary. No tests.

That way, you're sure you won't generate a wrong distinfo because you
fucked a test.

Re: UPDATE: php revamp

[Stuart Henderson]

On 2017/11/11 20:01, Martijn van Duren wrote:
> On 11/11/17 15:40, Stuart Henderson wrote:>> As for the php-fpm.conf, I only
> >> enabled the 7.0 (and 7.1) config for 5.6, this would make future updates
> >> easier instead of harder.
> > 
> > If the fpm config in a 5.6 or 7.0 update is changed upstream, the whole
> > file will have to be re-merged.
> > 
> > Why would a user want to have the same fpm config on 5.6 as 7.0 anyway?
> > Surely if the two are installed alongside each other at all, they would be
> > used for different sites?
> 
> Let's save that one until when we get there.
> > 
> >> You mist a few old (5.3-era) references and if we move suhosin out I
> >> would like to move -mysql, -sybase-ct, and -mssql to 5.6/Makefile while
> >> we're at it.
> >>
> >> OK for my version?
> > 
> > Sorry. I'm not going to be pushed here. I am trying to help get this
> > processed but I will only deal with manageable chunks, this already
> > turns my ~130 line diff into a ~300 line one. There's no advantage to
> > stacking up too much in one go.
> > 
> I'm no trying to push you, just trying to make the move more consistent,
> but if you feel strongly about it. Sure, go ahead with your patch.
> Just one request though (see below):
> 
> > Index: Makefile.inc
> > ===
> > RCS file: /cvs/ports/lang/php/Makefile.inc,v
> > retrieving revision 1.96
> > diff -u -p -r1.96 Makefile.inc
> > --- Makefile.inc24 Aug 2017 10:03:25 -  1.96
> > +++ Makefile.inc11 Nov 2017 13:16:04 -
> > @@ -8,7 +8,7 @@ COMMENT-fastcgi=stand-alone FastCGI ver
> >  PKGNAME-main?= php-${V}
> >  PKGNAME-fastcgi?=  php-fastcgi-${V}
> >  
> > -DISTFILES?=php-${V}.tar.bz2
> > +DISTFILES+=php-${V}.tar.bz2
> >  
> >  DISTNAME?= php-${V}
> >  CATEGORIES=lang www
> > @@ -20,7 +20,6 @@ MASTER_SITES= http://se.php.net/distrib
> > http://us.php.net/distributions/ \
> > http://no.php.net/distributions/ \
> > http://uk.php.net/distributions/
> > -MASTER_SITES0= https://download.suhosin.org/
> >  
> >  # UPGRADERS: please read BOTH the PHP and Zend licenses
> >  # and make sure they are safe before an upgrade
> > @@ -48,11 +47,6 @@ INI_TEMPLATES?=  development production
> >  # don't have.
> >  USE_LIBTOOL?=  No
> >  
> > -.if ${PV} != "7.0"
> > -FLAVORS=   no_suhosin
> > -.endif
> > -FLAVOR?=
> > -
> >  PATCHORIG= .orig.port
> >  CONFIGURE_STYLE=   autoconf
> >  AUTOCONF_VERSION?= 2.69
> > @@ -355,18 +349,6 @@ RUN_DEPENDS-main=  mail/femail,-chroot
> >  LIB_DEPENDS-fastcgi=   ${LIB_DEPENDS-main}
> >  RUN_DEPENDS-fastcgi=
> >  
> > -SUHOSIN_V= 0.9.38
> > -.if ${FLAVOR:Mno_suhosin} || ${PV} == "7.0"
> > -SUPDISTFILES=  suhosin-${SUHOSIN_V}.tar.gz:0
> > -.else
> > -DISTFILES+=suhosin-${SUHOSIN_V}.tar.gz:0
> > -PATCH_LIST=patch-* suhosin-*
> > -CONFIGURE_ARGS+=   --enable-suhosin
> > -
> > -pre-patch:
> > -   @mv ${WRKDIR}/suhosin-${SUHOSIN_V} ${WRKSRC}/ext/suhosin
> > -.endif
> > -
> >  pre-fake:
> > ${INSTALL_DATA_DIR} ${PREFIX}/${APACHE_MODULE_SUBDIR}/modules
> >  
> > @@ -384,11 +366,7 @@ pre-configure:
> >  MODULE_NAME-${i}=  ${i}
> >  DESCR-${i}=${.CURDIR}/../files/DESCR-${i}
> >  PKGNAME-${i}=  php-${i}-${V}
> > -.if ${V:M5.4*}
> > -PKGSPEC-${i}=  php-${i}->=5.4,<5.5
> > -.elif ${V:M5.5*}
> > -PKGSPEC-${i}=  php-${i}->=5.5,<5.6
> > -.elif ${V:M5.6*}
> > +.if ${V:M5.6*}
> >  PKGSPEC-${i}=  php-${i}->=5.6,<5.7
> >  .elif ${V:M7.0*}
> >  PKGSPEC-${i}=  php-${i}->=7.0,<7.1
> > Index: php.port.mk
> > ===
> > RCS file: /cvs/ports/lang/php/php.port.mk,v
> > retrieving revision 1.16
> > diff -u -p -r1.16 php.port.mk
> > --- php.port.mk 25 Apr 2017 11:26:43 -  1.16
> > +++ php.port.mk 11 Nov 2017 13:16:04 -
> > @@ -3,9 +3,7 @@
> >  CATEGORIES+=   lang/php
> >  
> >  MODPHP_VERSION?=   5.6
> > -.if ${MODPHP_VERSION} == 5.5
> > -MODPHP_VSPEC = >=${MODPHP_VERSION},<5.6
> > -.elif ${MODPHP_VERSION} == 5.6
> > +.if ${MODPHP_VERSION} == 5.6
> >  MODPHP_VSPEC = >=${MODPHP_VERSION},<5.7
> >  .elif ${MODPHP_VERSION} == 7.0
> >  MODPHP_VSPEC = >=${MODPHP_VERSION},<7.1
> > Index: 5.6/Makefile
> > ===
> > RCS file: /cvs/ports/lang/php/5.6/Makefile,v
> > retrieving revision 1.51
> > diff -u -p -r1.51 Makefile
> > --- 5.6/Makefile24 Aug 2017 10:52:41 -  1.51
> > +++ 5.6/Makefile11 Nov 2017 13:16:04 -
> > @@ -5,6 +5,24 @@ BROKEN-alpha=  pcre_jit_compile.c:65:2: e
> >  PV=5.6
> >  V= ${PV}.31
> >  
> > -WANTLIB-main+= ${COMPILER_LIBCXX} ncurses readline
> > 

Re: UPDATE: php revamp

[Martijn van Duren]

On 11/11/17 15:40, Stuart Henderson wrote:>> As for the php-fpm.conf, I only
>> enabled the 7.0 (and 7.1) config for 5.6, this would make future updates
>> easier instead of harder.
> 
> If the fpm config in a 5.6 or 7.0 update is changed upstream, the whole
> file will have to be re-merged.
> 
> Why would a user want to have the same fpm config on 5.6 as 7.0 anyway?
> Surely if the two are installed alongside each other at all, they would be
> used for different sites?

Let's save that one until when we get there.
> 
>> You mist a few old (5.3-era) references and if we move suhosin out I
>> would like to move -mysql, -sybase-ct, and -mssql to 5.6/Makefile while
>> we're at it.
>>
>> OK for my version?
> 
> Sorry. I'm not going to be pushed here. I am trying to help get this
> processed but I will only deal with manageable chunks, this already
> turns my ~130 line diff into a ~300 line one. There's no advantage to
> stacking up too much in one go.
> 
I'm no trying to push you, just trying to make the move more consistent,
but if you feel strongly about it. Sure, go ahead with your patch.
Just one request though (see below):

> Index: Makefile.inc
> ===
> RCS file: /cvs/ports/lang/php/Makefile.inc,v
> retrieving revision 1.96
> diff -u -p -r1.96 Makefile.inc
> --- Makefile.inc  24 Aug 2017 10:03:25 -  1.96
> +++ Makefile.inc  11 Nov 2017 13:16:04 -
> @@ -8,7 +8,7 @@ COMMENT-fastcgi=  stand-alone FastCGI ver
>  PKGNAME-main?=   php-${V}
>  PKGNAME-fastcgi?=php-fastcgi-${V}
>  
> -DISTFILES?=  php-${V}.tar.bz2
> +DISTFILES+=  php-${V}.tar.bz2
>  
>  DISTNAME?=   php-${V}
>  CATEGORIES=  lang www
> @@ -20,7 +20,6 @@ MASTER_SITES=   http://se.php.net/distrib
>   http://us.php.net/distributions/ \
>   http://no.php.net/distributions/ \
>   http://uk.php.net/distributions/
> -MASTER_SITES0=   https://download.suhosin.org/
>  
>  # UPGRADERS: please read BOTH the PHP and Zend licenses
>  # and make sure they are safe before an upgrade
> @@ -48,11 +47,6 @@ INI_TEMPLATES?=development production
>  # don't have.
>  USE_LIBTOOL?=No
>  
> -.if ${PV} != "7.0"
> -FLAVORS= no_suhosin
> -.endif
> -FLAVOR?=
> -
>  PATCHORIG=   .orig.port
>  CONFIGURE_STYLE= autoconf
>  AUTOCONF_VERSION?=   2.69
> @@ -355,18 +349,6 @@ RUN_DEPENDS-main=mail/femail,-chroot
>  LIB_DEPENDS-fastcgi= ${LIB_DEPENDS-main}
>  RUN_DEPENDS-fastcgi=
>  
> -SUHOSIN_V=   0.9.38
> -.if ${FLAVOR:Mno_suhosin} || ${PV} == "7.0"
> -SUPDISTFILES=suhosin-${SUHOSIN_V}.tar.gz:0
> -.else
> -DISTFILES+=  suhosin-${SUHOSIN_V}.tar.gz:0
> -PATCH_LIST=  patch-* suhosin-*
> -CONFIGURE_ARGS+= --enable-suhosin
> -
> -pre-patch:
> - @mv ${WRKDIR}/suhosin-${SUHOSIN_V} ${WRKSRC}/ext/suhosin
> -.endif
> -
>  pre-fake:
>   ${INSTALL_DATA_DIR} ${PREFIX}/${APACHE_MODULE_SUBDIR}/modules
>  
> @@ -384,11 +366,7 @@ pre-configure:
>  MODULE_NAME-${i}=${i}
>  DESCR-${i}=  ${.CURDIR}/../files/DESCR-${i}
>  PKGNAME-${i}=php-${i}-${V}
> -.if ${V:M5.4*}
> -PKGSPEC-${i}=php-${i}->=5.4,<5.5
> -.elif ${V:M5.5*}
> -PKGSPEC-${i}=php-${i}->=5.5,<5.6
> -.elif ${V:M5.6*}
> +.if ${V:M5.6*}
>  PKGSPEC-${i}=php-${i}->=5.6,<5.7
>  .elif ${V:M7.0*}
>  PKGSPEC-${i}=php-${i}->=7.0,<7.1
> Index: php.port.mk
> ===
> RCS file: /cvs/ports/lang/php/php.port.mk,v
> retrieving revision 1.16
> diff -u -p -r1.16 php.port.mk
> --- php.port.mk   25 Apr 2017 11:26:43 -  1.16
> +++ php.port.mk   11 Nov 2017 13:16:04 -
> @@ -3,9 +3,7 @@
>  CATEGORIES+= lang/php
>  
>  MODPHP_VERSION?= 5.6
> -.if ${MODPHP_VERSION} == 5.5
> -MODPHP_VSPEC = >=${MODPHP_VERSION},<5.6
> -.elif ${MODPHP_VERSION} == 5.6
> +.if ${MODPHP_VERSION} == 5.6
>  MODPHP_VSPEC = >=${MODPHP_VERSION},<5.7
>  .elif ${MODPHP_VERSION} == 7.0
>  MODPHP_VSPEC = >=${MODPHP_VERSION},<7.1
> Index: 5.6/Makefile
> ===
> RCS file: /cvs/ports/lang/php/5.6/Makefile,v
> retrieving revision 1.51
> diff -u -p -r1.51 Makefile
> --- 5.6/Makefile  24 Aug 2017 10:52:41 -  1.51
> +++ 5.6/Makefile  11 Nov 2017 13:16:04 -
> @@ -5,6 +5,24 @@ BROKEN-alpha=pcre_jit_compile.c:65:2: e
>  PV=  5.6
>  V=   ${PV}.31
>  
> -WANTLIB-main+=   ${COMPILER_LIBCXX} ncurses readline
> +MASTER_SITES0=   https://download.suhosin.org/
> +
> +WANTLIB-main+=   ${COMPILER_LIBCXX} ncurses readline
> +
> +FLAVORS= no_suhosin
> +FLAVOR?=
> +
> +SUHOSIN_V=   0.9.38
> +
> +.if ${FLAVOR:Mno_suhosin}
> +SUPDISTFILES=suhosin-${SUHOSIN_V}.tar.gz:0
> +.else
> 

Re: UPDATE: php revamp

[Stuart Henderson]

On 2017/11/11 15:23, Martijn van Duren wrote:
> On 11/11/17 14:22, Stuart Henderson wrote:
> > Leaving aside the splitting, which you know my feelings about from when
> > I replied after you first proposed this split, this diff as a whole is
> > too big, it's un-reviewable.
> 
> And that's why I originally presented it as a new port. The diff itself
> is indeed impossible to review.
> > 
> > A lot of patches are removed/changed without explanation. In particular
> > the huge patches to php-fpm.conf.in files are going to be *horrible* for
> > future updates.
> 
> Those were motivated in the mails.

"- Clean up patches. Some are unneeded, redundant, superfluous so keep
it to a minimum for maintainability."

That doesn't explain the diffs though. Really I think a patch-by-patch
explanation for what the changes do would be appropriate there.

> As for the php-fpm.conf, I only
> enabled the 7.0 (and 7.1) config for 5.6, this would make future updates
> easier instead of harder.

If the fpm config in a 5.6 or 7.0 update is changed upstream, the whole
file will have to be re-merged.

Why would a user want to have the same fpm config on 5.6 as 7.0 anyway?
Surely if the two are installed alongside each other at all, they would be
used for different sites?

> You mist a few old (5.3-era) references and if we move suhosin out I
> would like to move -mysql, -sybase-ct, and -mssql to 5.6/Makefile while
> we're at it.
> 
> OK for my version?

Sorry. I'm not going to be pushed here. I am trying to help get this
processed but I will only deal with manageable chunks, this already
turns my ~130 line diff into a ~300 line one. There's no advantage to
stacking up too much in one go.


> > 
> > Then I would suggest working patch-by-patch in the patches/ directory
> > (i.e. 5.6/patches/somepatch + 7.0/patches/somepatch, in one mail.
> > Discuss/adjust/commit, then move on to {5.6/7.0}/patches/anotherpatch).
> > 
> > (Of course none of this fixes the *real* [separate but related] problem
> > that users of the PHP ports run into: we have no scaffolding to provide
> > pecl modules for anything other than the "default" version).
> 
> I will look into that, but one thing at a time.
> 
> Index: Makefile.inc
> ===
> RCS file: /cvs/ports/lang/php/Makefile.inc,v
> retrieving revision 1.96
> diff -u -p -r1.96 Makefile.inc
> --- Makefile.inc  24 Aug 2017 10:03:25 -  1.96
> +++ Makefile.inc  11 Nov 2017 14:21:58 -
> @@ -8,7 +8,7 @@ COMMENT-fastcgi=  stand-alone FastCGI ver
>  PKGNAME-main?=   php-${V}
>  PKGNAME-fastcgi?=php-fastcgi-${V}
>  
> -DISTFILES?=  php-${V}.tar.bz2
> +DISTFILES+=  php-${V}.tar.bz2
>  
>  DISTNAME?=   php-${V}
>  CATEGORIES=  lang www
> @@ -20,7 +20,6 @@ MASTER_SITES=   http://se.php.net/distrib
>   http://us.php.net/distributions/ \
>   http://no.php.net/distributions/ \
>   http://uk.php.net/distributions/
> -MASTER_SITES0=   https://download.suhosin.org/
>  
>  # UPGRADERS: please read BOTH the PHP and Zend licenses
>  # and make sure they are safe before an upgrade
> @@ -48,11 +47,6 @@ INI_TEMPLATES?=development production
>  # don't have.
>  USE_LIBTOOL?=No
>  
> -.if ${PV} != "7.0"
> -FLAVORS= no_suhosin
> -.endif
> -FLAVOR?=
> -
>  PATCHORIG=   .orig.port
>  CONFIGURE_STYLE= autoconf
>  AUTOCONF_VERSION?=   2.69
> @@ -77,12 +71,8 @@ CONFIGURE_ARGS+=   --enable-shared \
>   --with-pdo-sqlite \
>   --enable-sqlite-utf8 \
>   --with-sqlite3 \
> - --program-suffix=-${PV}
> -
> -# readline is broken in PHP-5.3
> -.if ${PV} != 5.3
> -CONFIGURE_ARGS +=--with-readline
> -.endif
> + --program-suffix=-${PV} \
> + --with-readline
>  
>  # apache module
>  CONFIGURE_ARGS+= --with-apxs2=${LOCALBASE}/sbin/apxs2
> @@ -149,7 +139,7 @@ MULTI_PACKAGES+=  -gd
>  COMMENT-gd=  image manipulation extensions for php5
>  LIB_DEPENDS-gd=  graphics/jpeg \
>   graphics/png
> -.if ${PV} != "7.0"
> +.if ${PV} == "5.6"
>  LIB_DEPENDS-gd+= devel/t1lib
>  WANTLIB-gd+= t1>=5
>  .endif
> @@ -200,15 +190,6 @@ CONFIGURE_ARGS+= --with-mcrypt=shared,${
>  LIB_DEPENDS-mcrypt=  security/libmcrypt devel/libtool,-ltdl
>  WANTLIB-mcrypt=  mcrypt ltdl>=1 pthread
>  
> -.if ${PV} != "7.0"
> -# mysql
> -MULTI_PACKAGES+= -mysql
> -COMMENT-mysql=   mysql database access extensions for php5
> -CONFIGURE_ARGS+= --with-mysql=shared,${LOCALBASE}
> -LIB_DEPENDS-mysql=   databases/mariadb
> -WANTLIB-mysql=   pthread lib/mysql/mysqlclient
> -.endif
> -
>  # mysqli
>  MULTI_PACKAGES+= -mysqli
>  COMMENT-mysqli=  mysql database access extensions for php5
> @@ 

Re: UPDATE: php revamp

[Martijn van Duren]

On 11/11/17 14:22, Stuart Henderson wrote:
> Leaving aside the splitting, which you know my feelings about from when
> I replied after you first proposed this split, this diff as a whole is
> too big, it's un-reviewable.

And that's why I originally presented it as a new port. The diff itself
is indeed impossible to review.
> 
> A lot of patches are removed/changed without explanation. In particular
> the huge patches to php-fpm.conf.in files are going to be *horrible* for
> future updates.

Those were motivated in the mails. As for the php-fpm.conf, I only
enabled the 7.0 (and 7.1) config for 5.6, this would make future updates
easier instead of harder.
> 
> Some of the other changes can be broken down too. Let's get them into
> individual reviewable diffs as much as possible.

Will do.
> 
> Since adding 7.1 means copying patches around, I would suggest cleaning
> up the patches *before* adding 7.1 so that can be done from a cleaner
> (and diffable with 7.0) basis.

Sure.
> 
> To get the ball rolling here's a diff to remove the unused 5.5 chunks
> from .mk/Makefile.inc files and move the suhosin extension parts to 5.6
> only. (Maybe that can be refactored again later if/when suhosin7 gets
> in shape).
> 
> OK?

You mist a few old (5.3-era) references and if we move suhosin out I
would like to move -mysql, -sybase-ct, and -mssql to 5.6/Makefile while
we're at it.

OK for my version?
> 
> Then I would suggest working patch-by-patch in the patches/ directory
> (i.e. 5.6/patches/somepatch + 7.0/patches/somepatch, in one mail.
> Discuss/adjust/commit, then move on to {5.6/7.0}/patches/anotherpatch).
> 
> (Of course none of this fixes the *real* [separate but related] problem
> that users of the PHP ports run into: we have no scaffolding to provide
> pecl modules for anything other than the "default" version).

I will look into that, but one thing at a time.

Index: Makefile.inc
===
RCS file: /cvs/ports/lang/php/Makefile.inc,v
retrieving revision 1.96
diff -u -p -r1.96 Makefile.inc
--- Makefile.inc24 Aug 2017 10:03:25 -  1.96
+++ Makefile.inc11 Nov 2017 14:21:58 -
@@ -8,7 +8,7 @@ COMMENT-fastcgi=stand-alone FastCGI ver
 PKGNAME-main?= php-${V}
 PKGNAME-fastcgi?=  php-fastcgi-${V}
 
-DISTFILES?=php-${V}.tar.bz2
+DISTFILES+=php-${V}.tar.bz2
 
 DISTNAME?= php-${V}
 CATEGORIES=lang www
@@ -20,7 +20,6 @@ MASTER_SITES= http://se.php.net/distrib
http://us.php.net/distributions/ \
http://no.php.net/distributions/ \
http://uk.php.net/distributions/
-MASTER_SITES0= https://download.suhosin.org/
 
 # UPGRADERS: please read BOTH the PHP and Zend licenses
 # and make sure they are safe before an upgrade
@@ -48,11 +47,6 @@ INI_TEMPLATES?=  development production
 # don't have.
 USE_LIBTOOL?=  No
 
-.if ${PV} != "7.0"
-FLAVORS=   no_suhosin
-.endif
-FLAVOR?=
-
 PATCHORIG= .orig.port
 CONFIGURE_STYLE=   autoconf
 AUTOCONF_VERSION?= 2.69
@@ -77,12 +71,8 @@ CONFIGURE_ARGS+= --enable-shared \
--with-pdo-sqlite \
--enable-sqlite-utf8 \
--with-sqlite3 \
-   --program-suffix=-${PV}
-
-# readline is broken in PHP-5.3
-.if ${PV} != 5.3
-CONFIGURE_ARGS +=  --with-readline
-.endif
+   --program-suffix=-${PV} \
+   --with-readline
 
 # apache module
 CONFIGURE_ARGS+=   --with-apxs2=${LOCALBASE}/sbin/apxs2
@@ -149,7 +139,7 @@ MULTI_PACKAGES+=-gd
 COMMENT-gd=image manipulation extensions for php5
 LIB_DEPENDS-gd=graphics/jpeg \
graphics/png
-.if ${PV} != "7.0"
+.if ${PV} == "5.6"
 LIB_DEPENDS-gd+=   devel/t1lib
 WANTLIB-gd+=   t1>=5
 .endif
@@ -200,15 +190,6 @@ CONFIGURE_ARGS+=   --with-mcrypt=shared,${
 LIB_DEPENDS-mcrypt=security/libmcrypt devel/libtool,-ltdl
 WANTLIB-mcrypt=mcrypt ltdl>=1 pthread
 
-.if ${PV} != "7.0"
-# mysql
-MULTI_PACKAGES+=   -mysql
-COMMENT-mysql= mysql database access extensions for php5
-CONFIGURE_ARGS+=   --with-mysql=shared,${LOCALBASE}
-LIB_DEPENDS-mysql= databases/mariadb
-WANTLIB-mysql= pthread lib/mysql/mysqlclient
-.endif
-
 # mysqli
 MULTI_PACKAGES+=   -mysqli
 COMMENT-mysqli=mysql database access extensions for php5
@@ -222,9 +203,7 @@ COMMENT-odbc=   odbc database access exte
 CONFIGURE_ARGS+=--with-iodbc=shared,${LOCALBASE}
 LIB_DEPENDS-odbc=  databases/iodbc
 WANTLIB-odbc=  iodbc>=2 pthread
-.if ${PV} != "5.3"
 WANTLIB-odbc+= iodbcinst
-.endif
 
 # pcntl
 MULTI_PACKAGES+=   -pcntl
@@ -282,15 +261,6 @@ CONFIGURE_ARGS+=   --with-snmp=shared,${LO
 LIB_DEPENDS-snmp=  net/net-snmp
 

Re: UPDATE: php revamp

[Stuart Henderson]

Leaving aside the splitting, which you know my feelings about from when
I replied after you first proposed this split, this diff as a whole is
too big, it's un-reviewable.

A lot of patches are removed/changed without explanation. In particular
the huge patches to php-fpm.conf.in files are going to be *horrible* for
future updates.

Some of the other changes can be broken down too. Let's get them into
individual reviewable diffs as much as possible.

Since adding 7.1 means copying patches around, I would suggest cleaning
up the patches *before* adding 7.1 so that can be done from a cleaner
(and diffable with 7.0) basis.

To get the ball rolling here's a diff to remove the unused 5.5 chunks
from .mk/Makefile.inc files and move the suhosin extension parts to 5.6
only. (Maybe that can be refactored again later if/when suhosin7 gets
in shape).

OK?

Then I would suggest working patch-by-patch in the patches/ directory
(i.e. 5.6/patches/somepatch + 7.0/patches/somepatch, in one mail.
Discuss/adjust/commit, then move on to {5.6/7.0}/patches/anotherpatch).

(Of course none of this fixes the *real* [separate but related] problem
that users of the PHP ports run into: we have no scaffolding to provide
pecl modules for anything other than the "default" version).

Index: Makefile.inc
===
RCS file: /cvs/ports/lang/php/Makefile.inc,v
retrieving revision 1.96
diff -u -p -r1.96 Makefile.inc
--- Makefile.inc24 Aug 2017 10:03:25 -  1.96
+++ Makefile.inc11 Nov 2017 13:16:04 -
@@ -8,7 +8,7 @@ COMMENT-fastcgi=stand-alone FastCGI ver
 PKGNAME-main?= php-${V}
 PKGNAME-fastcgi?=  php-fastcgi-${V}
 
-DISTFILES?=php-${V}.tar.bz2
+DISTFILES+=php-${V}.tar.bz2
 
 DISTNAME?= php-${V}
 CATEGORIES=lang www
@@ -20,7 +20,6 @@ MASTER_SITES= http://se.php.net/distrib
http://us.php.net/distributions/ \
http://no.php.net/distributions/ \
http://uk.php.net/distributions/
-MASTER_SITES0= https://download.suhosin.org/
 
 # UPGRADERS: please read BOTH the PHP and Zend licenses
 # and make sure they are safe before an upgrade
@@ -48,11 +47,6 @@ INI_TEMPLATES?=  development production
 # don't have.
 USE_LIBTOOL?=  No
 
-.if ${PV} != "7.0"
-FLAVORS=   no_suhosin
-.endif
-FLAVOR?=
-
 PATCHORIG= .orig.port
 CONFIGURE_STYLE=   autoconf
 AUTOCONF_VERSION?= 2.69
@@ -355,18 +349,6 @@ RUN_DEPENDS-main=  mail/femail,-chroot
 LIB_DEPENDS-fastcgi=   ${LIB_DEPENDS-main}
 RUN_DEPENDS-fastcgi=
 
-SUHOSIN_V= 0.9.38
-.if ${FLAVOR:Mno_suhosin} || ${PV} == "7.0"
-SUPDISTFILES=  suhosin-${SUHOSIN_V}.tar.gz:0
-.else
-DISTFILES+=suhosin-${SUHOSIN_V}.tar.gz:0
-PATCH_LIST=patch-* suhosin-*
-CONFIGURE_ARGS+=   --enable-suhosin
-
-pre-patch:
-   @mv ${WRKDIR}/suhosin-${SUHOSIN_V} ${WRKSRC}/ext/suhosin
-.endif
-
 pre-fake:
${INSTALL_DATA_DIR} ${PREFIX}/${APACHE_MODULE_SUBDIR}/modules
 
@@ -384,11 +366,7 @@ pre-configure:
 MODULE_NAME-${i}=  ${i}
 DESCR-${i}=${.CURDIR}/../files/DESCR-${i}
 PKGNAME-${i}=  php-${i}-${V}
-.if ${V:M5.4*}
-PKGSPEC-${i}=  php-${i}->=5.4,<5.5
-.elif ${V:M5.5*}
-PKGSPEC-${i}=  php-${i}->=5.5,<5.6
-.elif ${V:M5.6*}
+.if ${V:M5.6*}
 PKGSPEC-${i}=  php-${i}->=5.6,<5.7
 .elif ${V:M7.0*}
 PKGSPEC-${i}=  php-${i}->=7.0,<7.1
Index: php.port.mk
===
RCS file: /cvs/ports/lang/php/php.port.mk,v
retrieving revision 1.16
diff -u -p -r1.16 php.port.mk
--- php.port.mk 25 Apr 2017 11:26:43 -  1.16
+++ php.port.mk 11 Nov 2017 13:16:04 -
@@ -3,9 +3,7 @@
 CATEGORIES+=   lang/php
 
 MODPHP_VERSION?=   5.6
-.if ${MODPHP_VERSION} == 5.5
-MODPHP_VSPEC = >=${MODPHP_VERSION},<5.6
-.elif ${MODPHP_VERSION} == 5.6
+.if ${MODPHP_VERSION} == 5.6
 MODPHP_VSPEC = >=${MODPHP_VERSION},<5.7
 .elif ${MODPHP_VERSION} == 7.0
 MODPHP_VSPEC = >=${MODPHP_VERSION},<7.1
Index: 5.6/Makefile
===
RCS file: /cvs/ports/lang/php/5.6/Makefile,v
retrieving revision 1.51
diff -u -p -r1.51 Makefile
--- 5.6/Makefile24 Aug 2017 10:52:41 -  1.51
+++ 5.6/Makefile11 Nov 2017 13:16:04 -
@@ -5,6 +5,24 @@ BROKEN-alpha=  pcre_jit_compile.c:65:2: e
 PV=5.6
 V= ${PV}.31
 
-WANTLIB-main+= ${COMPILER_LIBCXX} ncurses readline
+MASTER_SITES0= https://download.suhosin.org/
+
+WANTLIB-main+= ${COMPILER_LIBCXX} ncurses readline
+
+FLAVORS=   no_suhosin
+FLAVOR?=
+
+SUHOSIN_V= 0.9.38
+
+.if ${FLAVOR:Mno_suhosin}
+SUPDISTFILES=  suhosin-${SUHOSIN_V}.tar.gz:0
+.else
+DISTFILES+=suhosin-${SUHOSIN_V}.tar.gz:0
+PATCH_LIST=patch-* suhosin-*
+CONFIGURE_ARGS+= --enable-suhosin
+
+pre-patch:
+

Re: UPDATE: php revamp

[Anatoli]

Theoretically, it's possible to include with the base package a script 
that, given a path, would inspect the PHP code there and provide a list 
of modules that should be enabled, based on the official list of modules 
(http://php.net/manual/en/funcref.php) and the functions/classes list 
for each. It won't be 100% reliable like C compilation/linking, but in 
practice it could be a rather working approach for most users.


Even more theoretically, the base package could perform this operation 
semi-automatically, e.g. take the PHP code paths from the configs 
(though php could be started with alternative config via a cli param, 
but this is not the mainstream case), then check it, then install needed 
modules.


*From:* Stuart Henderson
*Sent:* Saturday, November 04, 2017 17:50
*To:* Martijn Van Duren
*Cc:* Antoine Jacoutot, Tom Van Looy, Robert Nagy, Ports, Kirill 
Bychkov, Gonzalo L. Rodriguez, Marc Espie

*Subject:* Re: UPDATE: php revamp

On 2017/11/04 12:06, Martijn van Duren wrote:


On 11/03/17 21:56, Marc Espie wrote:> See, this is exactly what I'm afraid of.

run-time depends can be a bitch. The stuff still packages, and stays that
way until somebody notices an issue... which often happens a few months
after the commits, and sometimes even after release.

This risk should be minimal, since I grepped through all the packages
in-tree that contain a .php file on all the functions and classes that
moved out of main.


The problem is, people updating or importing any php-package need to do
the same. And then it's harder than doing a bulk search at the tine of
change. It's trickier than perl/python packages using modules, because
there are no build time checks.

Re: UPDATE: php revamp

[Stuart Henderson]

On 2017/11/04 12:06, Martijn van Duren wrote:
> On 11/03/17 21:56, Marc Espie wrote:> See, this is exactly what I'm afraid of.
> > 
> > run-time depends can be a bitch. The stuff still packages, and stays that
> > way until somebody notices an issue... which often happens a few months
> > after the commits, and sometimes even after release.
> 
> This risk should be minimal, since I grepped through all the packages
> in-tree that contain a .php file on all the functions and classes that
> moved out of main.

The problem is, people updating or importing any php-package need to do
the same. And then it's harder than doing a bulk search at the tine of
change. It's trickier than perl/python packages using modules, because
there are no build time checks.

Re: UPDATE: php revamp

[Stuart Henderson]

On 2017/11/04 12:57, Tom Van Looy wrote:
> If you are a user, things like Drupal, Symfony, WordPress, Magento, ...
> have a requirements page that tells you what extensions you have to enable.

Yeah. Sometimes they even get it right..

Re: UPDATE: php revamp

[Tom Van Looy]

On Sat, Nov 4, 2017 at 12:13 PM, Marc Espie  wrote:

> Welcome to the world of actual distributions.  We are supposed to
> be the expert and to know better than the end user.
>
> There's nothing that prevents you from adding this kind of rationale
> to the actual package DESCR.
>
> One strong point of OpenBSD is that we actuall make this kind of
> decision.  Choosing best paths for software components, so that the
> end-user doesn't have to worry too much.
>
> I've never been a fan of debian where they split stuff into so
> many very small packages that you never know what to install.
>


If you are a user, things like Drupal, Symfony, WordPress, Magento, ...
have a requirements page that tells you what extensions you have to enable.
It's up to the developers of those systems to tell you what the
requirements are.

If you are a PHP developer writing actual software, in my opinion, you
should learn what the extensions are for. There is good documentation
available on php.net for developers.


Now, think like an end-user.  Assume they want to use php. What do
> they do ?  They add the main package. They try to run something.
> They discover one dependency is missing. They add that dependency.
> They do it another time...
>
> How many times are they going to do it ?
>
> The safe bet is that they usually give up after the 4th dependency,
> and just add *everything* that has php in it.
>
> Congrats, you just gave them enough rope so that they add fileinfo
> by default.
>


Let's make a comparison with let's say PF. Users try to run something, they
open a port, open another port, ... so how many ports do they open until
they just allow any to any? If users are lazy there is not much you can do
about it. What solution should OpenBSD provide for that? A default ruleset
that assumes they run smtp, serve http, use skype, etc?

No offense, I'm tying to understand your point of view.

Re: UPDATE: php revamp

[Marc Espie]

On Sat, Nov 04, 2017 at 12:06:09PM +0100, Martijn van Duren wrote:
> So what would be the desired requirements for this merge?
> - The module doesn't have any lib-depends to prevent pulling in all
> kinds of random packages.
> - The module must be a requirement for another port.
> - The module must not have any security implications.
> 
> If these are the requirements than the following packages would be
> merged back into -main (or more precisely the different -SAPI packages):
> - bcmath
> - calendar
> - ctype
> - dom (libxml is a required extension, so no new dependencies)
> - exif
> - fileinfo? (no external dependency)
> - ftp
> - json
> - mysqlnd
> - mysql (depends on mysqlnd driver)
> - mysqli (depends on mysqlnd driver)
> - pdo
> - pdo_mysql (depends on mysqlnd and pdo driver)
> - phar? (Would leave sparc64 broken)
> - simplexml (see dom)
> - soap (see dom)
> - sockets
> - sysvsem? (I currently don't know if this has security implications)
> - sysvshm? (I currently don't know if this has security implications)
> - tokenizer
> - wddx (see dom)
> - xmlreader (see dom)
> - xmlrpc (see dom)
> - xmlwrite (see dom)
> - zip
> 
> But would still leave the following as an invariables:
> - bz2 (external library - archivers/bzip2)
> - curl (external libarary - net/curl)
> - fileinfo? (security of this feature has been subject of debate before)
> - gd (extrenal libraries - graphics/{jpeg,png}
> - gettext (external library - devel/gettext)
> - gpm (external library - devel/gmp)
> - iconv (external library - converters/libiconv)
> - imap (external library - mail/alpine,-c-client)
> - intl (external library - textproc/icu4c)
> - ldap (external library - databases/openldap)
> - mbstring (external library - textproc/oniguruma)
> - mcrypt (external libraries - security/libmcrypt, devel/libtool,ltdl)
> - pcntl (security - process control)
> - pdo_pgsql (external library - databases/postgresql)
> - pgsql (external library - database/postgresql)
> - phar? (Should allow to build on sparc64 if we ignore the module there)
> - posix (security - does signals)
> - pspell (external library - textproc/aspell/core)
> - readline (libreadline, although that can be provided through base)
> - snmp (external library - net/netsnmp)
> - sqlite3 (external library - databases/sqlite3)
> - sysvsem? (I currently don't know if this has security implications)
> - sysvshm? (I currently don't know if this has security implications)
> - xsl (external library - textproc/libxslt)
> 
> This list is about 50/50 and might seem completely unintuitive to the
> end-user. What would people think about pdo_mysql being included over
> pdo_pgsql or pdo_sqlite3 without knowledge of this discussion? -
> They could assume mysql/mariadb is the preferred database for the
> OpenBSD project, or think that the OpenBSD devs forgot to include the
> pdo_mysql package and start asking questions on the mailing lists.
> Or why do I have all my xml-tools and its kitchensink, but not xsl?
> Same for sysvsem/sysvshm vs sysvmsg?
> What about bzip2, curl? pretty widely used while the sysv* modules
> are a rarity (I was surprised even a single port uses them).

Welcome to the world of actual distributions.  We are supposed to
be the expert and to know better than the end user.

There's nothing that prevents you from adding this kind of rationale
to the actual package DESCR.

One strong point of OpenBSD is that we actuall make this kind of
decision.  Choosing best paths for software components, so that the
end-user doesn't have to worry too much.

I've never been a fan of debian where they split stuff into so
many very small packages that you never know what to install.

Now, think like an end-user.  Assume they want to use php. What do
they do ?  They add the main package. They try to run something.
They discover one dependency is missing. They add that dependency.
They do it another time...

How many times are they going to do it ?

The safe bet is that they usually give up after the 4th dependency,
and just add *everything* that has php in it.

Congrats, you just gave them enough rope so that they add fileinfo
by default.

Re: UPDATE: php revamp

[Martijn van Duren]

On 11/03/17 21:56, Marc Espie wrote:> See, this is exactly what I'm afraid of.
> 
> run-time depends can be a bitch. The stuff still packages, and stays that
> way until somebody notices an issue... which often happens a few months
> after the commits, and sometimes even after release.

This risk should be minimal, since I grepped through all the packages
in-tree that contain a .php file on all the functions and classes that
moved out of main. Aside from that, currently the risk is about equal
because the admin already has to enable the RUN_DEPENDS modules.
Also note that the admin can still easily install the required module
when needed and is nothing more than a nuisance.
> 
> Does php complain as soon as you try to start the offending package, or
> only when you activate some functionality that depends on the extra
> plugin ?
> 
For module-dependency (e.g. pecl) it's at startup time (during ini-parsing)
(but as a warning unfortunately) and for methods/classes required at runtime
it's done lazily unfortunately.
> 
> I'm seriously way more happy with things breaking straight away during
> compilation than with these kinds of ticking time bombs.

I agree 100%, but unfortunately that's just how PHP works.
> 
> Invariably leads to breakage being noticed at the most inconvenient
> times.
> 
Agree, although I've done all I can think of to prevent this with this
move.
> 
> In the past, we've always cut up php according to two criteria:
> - modules that actually use more libraries (as in: pulling in more
> external stuff)
> - modules that actually have security aspects.
> 
> Getting more fine-grained is not really that useful, and will only
> lead to further issues down the road.
> 
> We already went that way for other things like gstreamer plugins,
> invariably cutting back to FEWER coarse grained modules sooner or
> later.

PHP's usecase can't be compared to that of gstreamer, because it's a
general purpose programming language.
> 
> I would rather this be done sooner rather than later.
> 
So what would be the desired requirements for this merge?
- The module doesn't have any lib-depends to prevent pulling in all
kinds of random packages.
- The module must be a requirement for another port.
- The module must not have any security implications.

If these are the requirements than the following packages would be
merged back into -main (or more precisely the different -SAPI packages):
- bcmath
- calendar
- ctype
- dom (libxml is a required extension, so no new dependencies)
- exif
- fileinfo? (no external dependency)
- ftp
- json
- mysqlnd
- mysql (depends on mysqlnd driver)
- mysqli (depends on mysqlnd driver)
- pdo
- pdo_mysql (depends on mysqlnd and pdo driver)
- phar? (Would leave sparc64 broken)
- simplexml (see dom)
- soap (see dom)
- sockets
- sysvsem? (I currently don't know if this has security implications)
- sysvshm? (I currently don't know if this has security implications)
- tokenizer
- wddx (see dom)
- xmlreader (see dom)
- xmlrpc (see dom)
- xmlwrite (see dom)
- zip

But would still leave the following as an invariables:
- bz2 (external library - archivers/bzip2)
- curl (external libarary - net/curl)
- fileinfo? (security of this feature has been subject of debate before)
- gd (extrenal libraries - graphics/{jpeg,png}
- gettext (external library - devel/gettext)
- gpm (external library - devel/gmp)
- iconv (external library - converters/libiconv)
- imap (external library - mail/alpine,-c-client)
- intl (external library - textproc/icu4c)
- ldap (external library - databases/openldap)
- mbstring (external library - textproc/oniguruma)
- mcrypt (external libraries - security/libmcrypt, devel/libtool,ltdl)
- pcntl (security - process control)
- pdo_pgsql (external library - databases/postgresql)
- pgsql (external library - database/postgresql)
- phar? (Should allow to build on sparc64 if we ignore the module there)
- posix (security - does signals)
- pspell (external library - textproc/aspell/core)
- readline (libreadline, although that can be provided through base)
- snmp (external library - net/netsnmp)
- sqlite3 (external library - databases/sqlite3)
- sysvsem? (I currently don't know if this has security implications)
- sysvshm? (I currently don't know if this has security implications)
- xsl (external library - textproc/libxslt)

This list is about 50/50 and might seem completely unintuitive to the
end-user. What would people think about pdo_mysql being included over
pdo_pgsql or pdo_sqlite3 without knowledge of this discussion? -
They could assume mysql/mariadb is the preferred database for the
OpenBSD project, or think that the OpenBSD devs forgot to include the
pdo_mysql package and start asking questions on the mailing lists.
Or why do I have all my xml-tools and its kitchensink, but not xsl?
Same for sysvsem/sysvshm vs sysvmsg?
What about bzip2, curl? pretty widely used while the sysv* modules
are a rarity (I was surprised even a single port uses them).

Even with the above ruleset both 

Re: UPDATE: php revamp

[Tom Van Looy]

On Fri, Nov 3, 2017 at 9:56 PM, Marc Espie  wrote:

> run-time depends can be a bitch. The stuff still packages, and stays that
> way until somebody notices an issue... which often happens a few months
> after the commits, and sometimes even after release.
>
> Does php complain as soon as you try to start the offending package, or
> only when you activate some functionality that depends on the extra
> plugin ?
>

It only starts complaining when you use a function that isn't there. So
yeah that would lead to possible trouble.

What if we enable the extensions by default when you install them? Given
that you install them, you probably want them enabled anyway. And that
would be a solution for this problem.

Re: UPDATE: php revamp

[Marc Espie]

On Fri, Nov 03, 2017 at 07:07:14PM +0100, Martijn van Duren wrote:
> That's no harder than the current situation. E.g. mail/roundcubemail
> currently has (extreme example):
> RUN_DEPENDS=lang/php/${MODPHP_VERSION},-pspell \
> lang/php/${MODPHP_VERSION},-zip
> While the new version just moves to:
> RUN_DEPENDS=lang/php/${MODPHP_VERSION},-ctype \
> lang/php/${MODPHP_VERSION},-dom \
> lang/php/${MODPHP_VERSION},-exif \
> lang/php/${MODPHP_VERSION},-fileinfo \
> lang/php/${MODPHP_VERSION},-iconv \
> lang/php/${MODPHP_VERSION},-json \
> lang/php/${MODPHP_VERSION},-mbstring \
> lang/php/${MODPHP_VERSION},-pdo \
> lang/php/${MODPHP_VERSION},-posix \
> lang/php/${MODPHP_VERSION},-pspell \
> lang/php/${MODPHP_VERSION},-sockets \
> lang/php/${MODPHP_VERSION},-simplexml \
> lang/php/${MODPHP_VERSION},-tokenizer \
> lang/php/${MODPHP_VERSION},-zip
> So the dependencies are pulled in at install-time, but the admin
> will have to enable these manually.
> Same goes for the few pecl packages, although these require
> the other modules at compile-time as well.
> E.g. pecl-http goes from from:
> RUN_DEPENDS+=   www/pecl-raphf \
> www/pecl-propro
> BUILD_DEPENDS+= ${RUN_DEPENDS}
> To:
> RUN_DEPENDS+=   www/pecl-raphf \
> www/pecl-propro \
> lang/php/${MODPHP_VERSION},-iconv
> BUILD_DEPENDS+= ${RUN_DEPENDS}
> 
> PHP usually complains in an understandable way if it can't find a
> certain module that it requires at runtime.
> 
> In short: the requirements for packages get a little bigger, but the 
> semantics don't change compared to the current situation. Also note
> that I would like to look into something like a phpctl tool that could
> automate the change of (some) ini-settings, including en-/disabling
> modules. But I intent to not bent my mind over that before this gets in.

See, this is exactly what I'm afraid of.

run-time depends can be a bitch. The stuff still packages, and stays that
way until somebody notices an issue... which often happens a few months
after the commits, and sometimes even after release.

Does php complain as soon as you try to start the offending package, or
only when you activate some functionality that depends on the extra
plugin ?


I'm seriously way more happy with things breaking straight away during
compilation than with these kinds of ticking time bombs.

Invariably leads to breakage being noticed at the most inconvenient
times.


In the past, we've always cut up php according to two criteria:
- modules that actually use more libraries (as in: pulling in more
external stuff)
- modules that actually have security aspects.

Getting more fine-grained is not really that useful, and will only
lead to further issues down the road.

We already went that way for other things like gstreamer plugins,
invariably cutting back to FEWER coarse grained modules sooner or
later.

I would rather this be done sooner rather than later.

Re: UPDATE: php revamp

[Martijn van Duren]

On 11/03/17 12:53, Marc Espie wrote:
> On Fri, Nov 03, 2017 at 10:07:33AM +0100, Antoine Jacoutot wrote:
>> Let's get this in and see how it flows. We can always put some components 
>> back
>> to -main if needed later.
>> I did like the fact that -main used to bundle the most used stuff, it made
>> handling php dependencies very easy. But as mentioned, let's go with your 
>> diff
>> and we shall see :-)
> 
> Small caveat: when we want to move back to the way things were later, this
> will mean some @pkgpath annotations for updates...
> 
> so it's slightly simpler if there are a few part we can merge now.

That's up to opponents of the new layout to propose. I'm open to some parts
to be merged back in, but I'm not going to suggest any.
> 
> trick question: ports that depend on php components, how hard are
> they to tweak with this patch ? assuming some components are no longer
> part of the main php package...
> 
That's no harder than the current situation. E.g. mail/roundcubemail
currently has (extreme example):
RUN_DEPENDS=lang/php/${MODPHP_VERSION},-pspell \
lang/php/${MODPHP_VERSION},-zip
While the new version just moves to:
RUN_DEPENDS=lang/php/${MODPHP_VERSION},-ctype \
lang/php/${MODPHP_VERSION},-dom \
lang/php/${MODPHP_VERSION},-exif \
lang/php/${MODPHP_VERSION},-fileinfo \
lang/php/${MODPHP_VERSION},-iconv \
lang/php/${MODPHP_VERSION},-json \
lang/php/${MODPHP_VERSION},-mbstring \
lang/php/${MODPHP_VERSION},-pdo \
lang/php/${MODPHP_VERSION},-posix \
lang/php/${MODPHP_VERSION},-pspell \
lang/php/${MODPHP_VERSION},-sockets \
lang/php/${MODPHP_VERSION},-simplexml \
lang/php/${MODPHP_VERSION},-tokenizer \
lang/php/${MODPHP_VERSION},-zip
So the dependencies are pulled in at install-time, but the admin
will have to enable these manually.
Same goes for the few pecl packages, although these require
the other modules at compile-time as well.
E.g. pecl-http goes from from:
RUN_DEPENDS+=   www/pecl-raphf \
www/pecl-propro
BUILD_DEPENDS+= ${RUN_DEPENDS}
To:
RUN_DEPENDS+=   www/pecl-raphf \
www/pecl-propro \
lang/php/${MODPHP_VERSION},-iconv
BUILD_DEPENDS+= ${RUN_DEPENDS}

PHP usually complains in an understandable way if it can't find a
certain module that it requires at runtime.

In short: the requirements for packages get a little bigger, but the 
semantics don't change compared to the current situation. Also note
that I would like to look into something like a phpctl tool that could
automate the change of (some) ini-settings, including en-/disabling
modules. But I intent to not bent my mind over that before this gets in.

martijn@

Re: UPDATE: php revamp

[Marc Espie]

On Fri, Nov 03, 2017 at 10:07:33AM +0100, Antoine Jacoutot wrote:
> Let's get this in and see how it flows. We can always put some components back
> to -main if needed later.
> I did like the fact that -main used to bundle the most used stuff, it made
> handling php dependencies very easy. But as mentioned, let's go with your diff
> and we shall see :-)

Small caveat: when we want to move back to the way things were later, this
will mean some @pkgpath annotations for updates...

so it's slightly simpler if there are a few part we can merge now.

trick question: ports that depend on php components, how hard are
they to tweak with this patch ? assuming some components are no longer
part of the main php package...

Re: UPDATE: php revamp

[Antoine Jacoutot]

On Fri, Nov 03, 2017 at 08:31:24AM +, Martijn van Duren wrote:
> On 11/02/17 22:59, Antoine Jacoutot wrote:
> > On Thu, Nov 02, 2017 at 09:30:34PM +, Stuart Henderson wrote:
> >> On 2017/11/02 21:41, Tom Van Looy wrote:
> >>> Hi
> >>>
> >>> Martijn did a very good job with this. This makes OpenBSD's PHP setup 
> >>> incredibly better. I
> >>> tested yesterdays patch and it works fine (I had trouble with the other 
> >>> ones). I built
> >>> everything and tested 7.1, 7.0, 5.6 with cli and fpm + extensions 
> >>> (opcache, curl, intl, etc.).
> >>>
> >>> So, looks good. I hope it gets committed soon. Thanks Marijn!
> >>>
> >>> Tom Van Looy
> >>>
> >>>
> >>
> >> It's a matter of opinion. I will cope but I really don't like the 
> >> FreeBSD-style
> >> micro splitting.
> > 
> > +1
> > 
> As I stated in my original email I'm not against moving some components
> back into the main compared to my version, but keeping e.g. WDDX and
> readline compiled in doesn't seem logical at all.
> I went for splitting everything out because that's my preferred way and
> it's the clearest and cleanest base to start from. If people want
> components kept in the main package they can just speak up, but so far
> nobody did.

Let's get this in and see how it flows. We can always put some components back
to -main if needed later.
I did like the fact that -main used to bundle the most used stuff, it made
handling php dependencies very easy. But as mentioned, let's go with your diff
and we shall see :-)

-- 
Antoine

Re: UPDATE: php revamp

[Tom Van Looy]

On Thu, Nov 2, 2017 at 10:59 PM, Antoine Jacoutot 
wrote:

> On Thu, Nov 02, 2017 at 09:30:34PM +, Stuart Henderson wrote:
> > It's a matter of opinion. I will cope but I really don't like the
> FreeBSD-style
> > micro splitting.
>
> +1
>

I don't see that as a problem but I get the point. I don't mind having all
extensions installed by default, like opcache, curl, readline, intl, etc.
are often used. The thing I like about the new approach is that they are
loadable modules and disabled by default. Like Martijn says, it doesn't
make sense to have WDDX, readline etc. compiled in.

I do like the fact that you have to pick an SAPI now.

Re: UPDATE: php revamp

[Martijn van Duren]

On 11/02/17 22:59, Antoine Jacoutot wrote:
> On Thu, Nov 02, 2017 at 09:30:34PM +, Stuart Henderson wrote:
>> On 2017/11/02 21:41, Tom Van Looy wrote:
>>> Hi
>>>
>>> Martijn did a very good job with this. This makes OpenBSD's PHP setup 
>>> incredibly better. I
>>> tested yesterdays patch and it works fine (I had trouble with the other 
>>> ones). I built
>>> everything and tested 7.1, 7.0, 5.6 with cli and fpm + extensions (opcache, 
>>> curl, intl, etc.).
>>>
>>> So, looks good. I hope it gets committed soon. Thanks Marijn!
>>>
>>> Tom Van Looy
>>>
>>>
>>
>> It's a matter of opinion. I will cope but I really don't like the 
>> FreeBSD-style
>> micro splitting.
> 
> +1
> 
As I stated in my original email I'm not against moving some components
back into the main compared to my version, but keeping e.g. WDDX and
readline compiled in doesn't seem logical at all.
I went for splitting everything out because that's my preferred way and
it's the clearest and cleanest base to start from. If people want
components kept in the main package they can just speak up, but so far
nobody did.

martijn@

Re: UPDATE: php revamp

[Antoine Jacoutot]

On Thu, Nov 02, 2017 at 09:30:34PM +, Stuart Henderson wrote:
> On 2017/11/02 21:41, Tom Van Looy wrote:
> > Hi
> > 
> > Martijn did a very good job with this. This makes OpenBSD's PHP setup 
> > incredibly better. I
> > tested yesterdays patch and it works fine (I had trouble with the other 
> > ones). I built
> > everything and tested 7.1, 7.0, 5.6 with cli and fpm + extensions (opcache, 
> > curl, intl, etc.).
> > 
> > So, looks good. I hope it gets committed soon. Thanks Marijn!
> > 
> > Tom Van Looy
> > 
> > 
> 
> It's a matter of opinion. I will cope but I really don't like the 
> FreeBSD-style
> micro splitting.

+1

-- 
Antoine

Re: UPDATE: php revamp

[Stuart Henderson]

On 2017/11/02 21:41, Tom Van Looy wrote:
> Hi
> 
> Martijn did a very good job with this. This makes OpenBSD's PHP setup 
> incredibly better. I
> tested yesterdays patch and it works fine (I had trouble with the other 
> ones). I built
> everything and tested 7.1, 7.0, 5.6 with cli and fpm + extensions (opcache, 
> curl, intl, etc.).
> 
> So, looks good. I hope it gets committed soon. Thanks Marijn!
> 
> Tom Van Looy
> 
> 

It's a matter of opinion. I will cope but I really don't like the FreeBSD-style
micro splitting.

Re: UPDATE: php revamp

[Tom Van Looy]

Hi

Martijn did a very good job with this. This makes OpenBSD's PHP setup
incredibly better. I tested yesterdays patch and it works fine (I had
trouble with the other ones). I built everything and tested 7.1, 7.0, 5.6
with cli and fpm + extensions (opcache, curl, intl, etc.).

So, looks good. I hope it gets committed soon. Thanks Marijn!

Tom Van Looy

Re: UPDATE: php revamp

[Martijn van Duren]

On 10/12/17 17:47, Tom Van Looy wrote:
> Hi Martijn
> 
> Maybe it is a good idea to just remove 7.0 and not introduce 7.1 anymore.
> Because 7.2 is planned for release on October 26. There will be plenty of
> time to test this release before 6.3. What do you think?
> 
Maintaining an extra version isn't that bad, since all versions share
almost everything. It might save some extra plumbing if we'd stick with
one version, but as long there's multiple supported PHP versions
upstream I don't see a reason to not include them all, since the
plumbing is already there.

martijn@

Re: UPDATE: php revamp

[Stuart Henderson]

5.3/5.4 got upgraded via @pkgpath when they stopped being the "main" ports 
version of php. 5.5 isn't going to be installed via dependencies any more 
so people who installed it will have asked for it specifically, so it 
doesn't make much sense to auto update it via @pkgpath, so adding a quirk 
to say that it's obsolete is going to be enough and is fairly simple.


--
 Sent from a phone, apologies for poor formatting.



On 28 August 2017 2:56:44 pm Martijn van Duren 
 wrote:



On 08/28/17 14:02, Stuart Henderson wrote:

On 2017/08/27 19:37, Martijn van Duren wrote:

On 08/27/17 19:31, Robert Nagy wrote:
Yeah let's keep php as is for 6.2, you can remove 5.5 and add 7.1 but 
that's it.

After unlock we can unleash hell on the tree.


Then I'd like to propose to just remove 5.5.

Adding 7.1 would either backporting extra fixes from my patch, or keep it close
to the way 7.0 is right now (including some ugly hacks in Makefile.inc), which
would further complicate things for me later on.

OK?


OK as far as it goes, but it needs quirks parts too.


I'm not quite clear on the quirks part:
The removal of PHP 5.3 and 5.4 don't seem to have any quirks entry
(based on both Quirks.pm and ports-changes@) and Quirks.pm doesn't seem
to have any transition based upon the removal of a specific version. So
what would these entries look like (if still applicable), and should it
be based on a removal (obsolete_reason), or a transition to 5.6
(stem_extensions)?



martijn@


On (2017-08-27 13:50), Stuart Henderson wrote:

I would be ok with killing 5.5 and adding 7.1 but think it's the wrong time
in the release cycle for anything more complex.
--
 Sent from a phone, apologies for poor formatting.




Index: Makefile
===
RCS file: /cvs/ports/lang/php/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile28 Apr 2016 18:19:23 -  1.11
+++ Makefile27 Aug 2017 17:36:28 -
@@ -1,7 +1,6 @@
 # $OpenBSD: Makefile,v 1.11 2016/04/28 18:19:23 sthen Exp $

 SUBDIR =
-SUBDIR += 5.5
 SUBDIR += 5.6
 SUBDIR += 7.0

Index: Makefile.inc
===
RCS file: /cvs/ports/lang/php/Makefile.inc,v
retrieving revision 1.96
diff -u -p -r1.96 Makefile.inc
--- Makefile.inc24 Aug 2017 10:03:25 -  1.96
+++ Makefile.inc27 Aug 2017 17:36:28 -
@@ -78,11 +78,7 @@ CONFIGURE_ARGS+= --enable-shared \
--enable-sqlite-utf8 \
--with-sqlite3 \
--program-suffix=-${PV}
-
-# readline is broken in PHP-5.3
-.if ${PV} != 5.3
 CONFIGURE_ARGS +=  --with-readline
-.endif

 # apache module
 CONFIGURE_ARGS+=   --with-apxs2=${LOCALBASE}/sbin/apxs2
@@ -221,10 +217,8 @@ MULTI_PACKAGES+=   -odbc
 COMMENT-odbc=  odbc database access extensions for php5
 CONFIGURE_ARGS+=--with-iodbc=shared,${LOCALBASE}
 LIB_DEPENDS-odbc=  databases/iodbc
-WANTLIB-odbc=  iodbc>=2 pthread
-.if ${PV} != "5.3"
-WANTLIB-odbc+= iodbcinst
-.endif
+WANTLIB-odbc=  iodbc>=2 pthread \
+   iodbcinst

 # pcntl
 MULTI_PACKAGES+=   -pcntl
@@ -347,7 +341,6 @@ PHPXS_SUBST+= -e 's,${i},${${i}},'
 WANTLIB-main+= c crypto iconv intl lzma m pthread ssl xml2>=8 z
 WANTLIB-main+= ncurses readline ${COMPILER_LIBCXX}

-# php 5.4/5.5 : WANTLIB-main += ${COMPILER_LIBCXX}
 WANTLIB-fastcgi=   ${WANTLIB-main}
 LIB_DEPENDS-main=  devel/gettext \
textproc/libxml
@@ -384,11 +377,7 @@ pre-configure:
 MODULE_NAME-${i}=  ${i}
 DESCR-${i}=${.CURDIR}/../files/DESCR-${i}
 PKGNAME-${i}=  php-${i}-${V}
-.if ${V:M5.4*}
-PKGSPEC-${i}=  php-${i}->=5.4,<5.5
-.elif ${V:M5.5*}
-PKGSPEC-${i}=  php-${i}->=5.5,<5.6
-.elif ${V:M5.6*}
+.if ${V:M5.6*}
 PKGSPEC-${i}=  php-${i}->=5.6,<5.7
 .elif ${V:M7.0*}
 PKGSPEC-${i}=  php-${i}->=7.0,<7.1

Re: UPDATE: php revamp

[Gonzalo L. Rodriguez]

Initial test on nextcloud looks good.

Thanks!

Ok so far.

On [27/08/17] [07:37P], Martijn van Duren wrote:
; On 08/27/17 19:31, Robert Nagy wrote:
; > Yeah let's keep php as is for 6.2, you can remove 5.5 and add 7.1 but 
that's it.
; > After unlock we can unleash hell on the tree.
; 
; Then I'd like to propose to just remove 5.5.
; 
; Adding 7.1 would either backporting extra fixes from my patch, or keep it 
close
; to the way 7.0 is right now (including some ugly hacks in Makefile.inc), which
; would further complicate things for me later on.
; 
; OK?
; 
; martijn@
; > 
; > On (2017-08-27 13:50), Stuart Henderson wrote:
; >> I would be ok with killing 5.5 and adding 7.1 but think it's the wrong time
; >> in the release cycle for anything more complex.
; >> -- 
; >>  Sent from a phone, apologies for poor formatting.
; >>
; >>
; >>
; Index: Makefile
; ===
; RCS file: /cvs/ports/lang/php/Makefile,v
; retrieving revision 1.11
; diff -u -p -r1.11 Makefile
; --- Makefile  28 Apr 2016 18:19:23 -  1.11
; +++ Makefile  27 Aug 2017 17:36:28 -
; @@ -1,7 +1,6 @@
;  # $OpenBSD: Makefile,v 1.11 2016/04/28 18:19:23 sthen Exp $
;  
;  SUBDIR =
; -SUBDIR += 5.5
;  SUBDIR += 5.6
;  SUBDIR += 7.0
;  
; Index: Makefile.inc
; ===
; RCS file: /cvs/ports/lang/php/Makefile.inc,v
; retrieving revision 1.96
; diff -u -p -r1.96 Makefile.inc
; --- Makefile.inc  24 Aug 2017 10:03:25 -  1.96
; +++ Makefile.inc  27 Aug 2017 17:36:28 -
; @@ -78,11 +78,7 @@ CONFIGURE_ARGS+=   --enable-shared \
;   --enable-sqlite-utf8 \
;   --with-sqlite3 \
;   --program-suffix=-${PV}
; -
; -# readline is broken in PHP-5.3
; -.if ${PV} != 5.3
;  CONFIGURE_ARGS +=--with-readline
; -.endif
;  
;  # apache module
;  CONFIGURE_ARGS+= --with-apxs2=${LOCALBASE}/sbin/apxs2
; @@ -221,10 +217,8 @@ MULTI_PACKAGES+= -odbc
;  COMMENT-odbc=odbc database access extensions for php5
;  CONFIGURE_ARGS+=--with-iodbc=shared,${LOCALBASE}
;  LIB_DEPENDS-odbc=databases/iodbc
; -WANTLIB-odbc=iodbc>=2 pthread
; -.if ${PV} != "5.3"
; -WANTLIB-odbc+=   iodbcinst
; -.endif
; +WANTLIB-odbc=iodbc>=2 pthread \
; + iodbcinst
;  
;  # pcntl
;  MULTI_PACKAGES+= -pcntl
; @@ -347,7 +341,6 @@ PHPXS_SUBST+= -e 's,${i},${${i}},'
;  WANTLIB-main+=   c crypto iconv intl lzma m pthread ssl xml2>=8 z
;  WANTLIB-main+=   ncurses readline ${COMPILER_LIBCXX}
;  
; -# php 5.4/5.5 : WANTLIB-main += ${COMPILER_LIBCXX}
;  WANTLIB-fastcgi= ${WANTLIB-main}
;  LIB_DEPENDS-main=devel/gettext \
;   textproc/libxml
; @@ -384,11 +377,7 @@ pre-configure:
;  MODULE_NAME-${i}=${i}
;  DESCR-${i}=  ${.CURDIR}/../files/DESCR-${i}
;  PKGNAME-${i}=php-${i}-${V}
; -.if ${V:M5.4*}
; -PKGSPEC-${i}=php-${i}->=5.4,<5.5
; -.elif ${V:M5.5*}
; -PKGSPEC-${i}=php-${i}->=5.5,<5.6
; -.elif ${V:M5.6*}
; +.if ${V:M5.6*}
;  PKGSPEC-${i}=php-${i}->=5.6,<5.7
;  .elif ${V:M7.0*}
;  PKGSPEC-${i}=php-${i}->=7.0,<7.1
; 

-- 
Sending from my toaster.

Re: UPDATE: php revamp

[Stuart Henderson]

On 2017/08/27 19:37, Martijn van Duren wrote:
> On 08/27/17 19:31, Robert Nagy wrote:
> > Yeah let's keep php as is for 6.2, you can remove 5.5 and add 7.1 but 
> > that's it.
> > After unlock we can unleash hell on the tree.
> 
> Then I'd like to propose to just remove 5.5.
> 
> Adding 7.1 would either backporting extra fixes from my patch, or keep it 
> close
> to the way 7.0 is right now (including some ugly hacks in Makefile.inc), which
> would further complicate things for me later on.
> 
> OK?

OK as far as it goes, but it needs quirks parts too.


> martijn@
> > 
> > On (2017-08-27 13:50), Stuart Henderson wrote:
> >> I would be ok with killing 5.5 and adding 7.1 but think it's the wrong time
> >> in the release cycle for anything more complex.
> >> -- 
> >>  Sent from a phone, apologies for poor formatting.
> >>
> >>
> >>
> Index: Makefile
> ===
> RCS file: /cvs/ports/lang/php/Makefile,v
> retrieving revision 1.11
> diff -u -p -r1.11 Makefile
> --- Makefile  28 Apr 2016 18:19:23 -  1.11
> +++ Makefile  27 Aug 2017 17:36:28 -
> @@ -1,7 +1,6 @@
>  # $OpenBSD: Makefile,v 1.11 2016/04/28 18:19:23 sthen Exp $
>  
>  SUBDIR =
> -SUBDIR += 5.5
>  SUBDIR += 5.6
>  SUBDIR += 7.0
>  
> Index: Makefile.inc
> ===
> RCS file: /cvs/ports/lang/php/Makefile.inc,v
> retrieving revision 1.96
> diff -u -p -r1.96 Makefile.inc
> --- Makefile.inc  24 Aug 2017 10:03:25 -  1.96
> +++ Makefile.inc  27 Aug 2017 17:36:28 -
> @@ -78,11 +78,7 @@ CONFIGURE_ARGS+=   --enable-shared \
>   --enable-sqlite-utf8 \
>   --with-sqlite3 \
>   --program-suffix=-${PV}
> -
> -# readline is broken in PHP-5.3
> -.if ${PV} != 5.3
>  CONFIGURE_ARGS +=--with-readline
> -.endif
>  
>  # apache module
>  CONFIGURE_ARGS+= --with-apxs2=${LOCALBASE}/sbin/apxs2
> @@ -221,10 +217,8 @@ MULTI_PACKAGES+= -odbc
>  COMMENT-odbc=odbc database access extensions for php5
>  CONFIGURE_ARGS+=--with-iodbc=shared,${LOCALBASE}
>  LIB_DEPENDS-odbc=databases/iodbc
> -WANTLIB-odbc=iodbc>=2 pthread
> -.if ${PV} != "5.3"
> -WANTLIB-odbc+=   iodbcinst
> -.endif
> +WANTLIB-odbc=iodbc>=2 pthread \
> + iodbcinst
>  
>  # pcntl
>  MULTI_PACKAGES+= -pcntl
> @@ -347,7 +341,6 @@ PHPXS_SUBST+= -e 's,${i},${${i}},'
>  WANTLIB-main+=   c crypto iconv intl lzma m pthread ssl xml2>=8 z
>  WANTLIB-main+=   ncurses readline ${COMPILER_LIBCXX}
>  
> -# php 5.4/5.5 : WANTLIB-main += ${COMPILER_LIBCXX}
>  WANTLIB-fastcgi= ${WANTLIB-main}
>  LIB_DEPENDS-main=devel/gettext \
>   textproc/libxml
> @@ -384,11 +377,7 @@ pre-configure:
>  MODULE_NAME-${i}=${i}
>  DESCR-${i}=  ${.CURDIR}/../files/DESCR-${i}
>  PKGNAME-${i}=php-${i}-${V}
> -.if ${V:M5.4*}
> -PKGSPEC-${i}=php-${i}->=5.4,<5.5
> -.elif ${V:M5.5*}
> -PKGSPEC-${i}=php-${i}->=5.5,<5.6
> -.elif ${V:M5.6*}
> +.if ${V:M5.6*}
>  PKGSPEC-${i}=php-${i}->=5.6,<5.7
>  .elif ${V:M7.0*}
>  PKGSPEC-${i}=php-${i}->=7.0,<7.1

Re: UPDATE: php revamp

[Martijn van Duren]

On 08/27/17 19:31, Robert Nagy wrote:
> Yeah let's keep php as is for 6.2, you can remove 5.5 and add 7.1 but that's 
> it.
> After unlock we can unleash hell on the tree.

Then I'd like to propose to just remove 5.5.

Adding 7.1 would either backporting extra fixes from my patch, or keep it close
to the way 7.0 is right now (including some ugly hacks in Makefile.inc), which
would further complicate things for me later on.

OK?

martijn@
> 
> On (2017-08-27 13:50), Stuart Henderson wrote:
>> I would be ok with killing 5.5 and adding 7.1 but think it's the wrong time
>> in the release cycle for anything more complex.
>> -- 
>>  Sent from a phone, apologies for poor formatting.
>>
>>
>>
Index: Makefile
===
RCS file: /cvs/ports/lang/php/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile28 Apr 2016 18:19:23 -  1.11
+++ Makefile27 Aug 2017 17:36:28 -
@@ -1,7 +1,6 @@
 # $OpenBSD: Makefile,v 1.11 2016/04/28 18:19:23 sthen Exp $
 
 SUBDIR =
-SUBDIR += 5.5
 SUBDIR += 5.6
 SUBDIR += 7.0
 
Index: Makefile.inc
===
RCS file: /cvs/ports/lang/php/Makefile.inc,v
retrieving revision 1.96
diff -u -p -r1.96 Makefile.inc
--- Makefile.inc24 Aug 2017 10:03:25 -  1.96
+++ Makefile.inc27 Aug 2017 17:36:28 -
@@ -78,11 +78,7 @@ CONFIGURE_ARGS+= --enable-shared \
--enable-sqlite-utf8 \
--with-sqlite3 \
--program-suffix=-${PV}
-
-# readline is broken in PHP-5.3
-.if ${PV} != 5.3
 CONFIGURE_ARGS +=  --with-readline
-.endif
 
 # apache module
 CONFIGURE_ARGS+=   --with-apxs2=${LOCALBASE}/sbin/apxs2
@@ -221,10 +217,8 @@ MULTI_PACKAGES+=   -odbc
 COMMENT-odbc=  odbc database access extensions for php5
 CONFIGURE_ARGS+=--with-iodbc=shared,${LOCALBASE}
 LIB_DEPENDS-odbc=  databases/iodbc
-WANTLIB-odbc=  iodbc>=2 pthread
-.if ${PV} != "5.3"
-WANTLIB-odbc+= iodbcinst
-.endif
+WANTLIB-odbc=  iodbc>=2 pthread \
+   iodbcinst
 
 # pcntl
 MULTI_PACKAGES+=   -pcntl
@@ -347,7 +341,6 @@ PHPXS_SUBST+= -e 's,${i},${${i}},'
 WANTLIB-main+= c crypto iconv intl lzma m pthread ssl xml2>=8 z
 WANTLIB-main+= ncurses readline ${COMPILER_LIBCXX}
 
-# php 5.4/5.5 : WANTLIB-main += ${COMPILER_LIBCXX}
 WANTLIB-fastcgi=   ${WANTLIB-main}
 LIB_DEPENDS-main=  devel/gettext \
textproc/libxml
@@ -384,11 +377,7 @@ pre-configure:
 MODULE_NAME-${i}=  ${i}
 DESCR-${i}=${.CURDIR}/../files/DESCR-${i}
 PKGNAME-${i}=  php-${i}-${V}
-.if ${V:M5.4*}
-PKGSPEC-${i}=  php-${i}->=5.4,<5.5
-.elif ${V:M5.5*}
-PKGSPEC-${i}=  php-${i}->=5.5,<5.6
-.elif ${V:M5.6*}
+.if ${V:M5.6*}
 PKGSPEC-${i}=  php-${i}->=5.6,<5.7
 .elif ${V:M7.0*}
 PKGSPEC-${i}=  php-${i}->=7.0,<7.1

Re: UPDATE: php revamp

[Antoine Jacoutot]

On Sun, Jul 02, 2017 at 07:56:50PM +0200, Robert Nagy wrote:
> Hi
> 
> Antoine, can you please push this into a bulk?

If I could have a full diff, that'd make it easier.
I am a bit worried about dependant ports, we are going to look deep into them to
add missing php modules because of the split.

> 
> On (2017-07-02 19:52), Martijn van Duren wrote:
> > Hello ports@,
> > 
> > Last couple of months I've been busy getting to know the OpenBSD ports 
> > system and the php build environment.
> > The main reason being my need for functionality at my $DAYJOB which 
> > isn't offered by the default php install on OpenBSD. Most notably php 
> > 7.1 and chroot (the php function).
> > 
> > During my quest I ended up touching about every part of the port and 
> > I'm currently quite happy with the result, although there's still some 
> > things I want to touch later on.
> > 
> > Some of the highlights I've done:
> > - Remove PHP 5.5. It's dead upstream for almost a year, so there's no 
> > need to keep it on OpenBSD.
> > - Clean up the CONFIGURE_ARGS. There were some arguments there that 
> > were simply not in PHP anymore.
> > - Move some deprecated modules into the PHP 5.6 Makefile. This keeps 
> > the Makefile.inc cleaner of if/else bloat.
> > - Replace the -fastcgi port with -cgi. -cgi is the official name and 
> > for fastcgi needs -fpm is recommended. This avoids confusion.
> > - Move modules to their own subpackage where possible. I don't like my 
> > clean php install having ftp or wddx. Let people make up their own mind.
> > - Remove unused dependencies (e.g. mariadb isn't needed when building 
> > with mysqlnd)
> > - Move every SAPI to their own subpackage. People running -fpm don't 
> > need mod_php or -cgi.
> > - Move the extension headers to their corresponding subpackage.
> > - Clean up the build environment. YACC=, USE_LIBTOOL, etc don't seem to 
> > be needed (anymore).
> > - Clean up patches. Some are unneeded, redundant, superfluous so keep 
> > it to a minimum for maintainability.
> > - Subpackages requiring another module have those dependencies. (e.g. 
> > installing -pdo_mysql also pulls in -pdo and -mysqlnd)
> > - Install phar and disable it on sparc64. This should allow us to have 
> > php on sparc64, without phar support. Untested for lack of hardware.
> > - Enable the chroot function by default. This function normally gets 
> > disabled if any SAPI other than -cli, -cgi, or -embed is compiled.
> > I reckon that if the chroot function is usable the code is running as 
> > root and you have bigger problems than a php server locking itself out 
> > of your main filesystem.
> > - Allow phpize to work without --with-php-config.
> > - Try to rely on other packages where code would be otherwise compiled 
> > in. E.g. devel/pcre for the pcre module and textproc/oniguruma for 
> > mbstring. These libraries are also packaged inside PHP if not available
> > on the main system.
> > - Miscellaneous cleanup
> > 
> > For the packages this means the following:
> > Removed:
> > - php-fastcgi
> > Added:
> > - php-apxs2
> > - php-bcmath
> > - php-calendar
> > - php-cgi
> > - php-cli
> > - php-ctype
> > - php-dom
> > - php-enchant
> > - php-exif
> > - php-fileinfo
> > - php-fpm
> > - php-ftp
> > - php-gettext
> > - php-iconv
> > - php-json
> > - php-mbstring
> > - php-mysqlnd
> > - php-opcache
> > - php-pdo
> > - php-pdo_sqlite
> > - php-phar
> > - php-posix
> > - php-readline
> > - php-simplexml
> > - php-sockets
> > - php-sqlite3
> > - php-sysvmsg
> > - php-sysvsem
> > - php-sysvshm
> > - php-tokenizer
> > - php-wddx
> > - php-xmlreader
> > - php-xmlwriter
> > Modules moved to shared components:
> > - bcmath
> > - calendar
> > - ctype
> > - dom
> > - exif
> > - fileinfo
> > - ftp
> > - gettext
> > - iconv
> > - json
> > - mbstring
> > - mysqlnd
> > - PDO
> > - pdo_sqlite
> > - Phar
> > - posix
> > - readline
> > - SimpleXML
> > - sockets
> > - sqlite3
> > - sysvmsg
> > - sysvsem
> > - sysvshm
> > - tokenizer
> > - wddx
> > - xmlreader
> > - xmlwriter
> > Modules kept compiled in:
> > - Core (for obvious reasons)
> > - date (can't be build stand-alone)
> > - ereg (removed in php 7.0, not worth the effort, also pcre is in 
> > default install)
> > - filter (can't be build stand-alone)
> > - hash (required to be built-in for phar hash-checking)
> > - libxml (can't be build stand-alone)
> > - openssl (allow tls as a Stream Socket Transport in a default install)
> > - pcre (can't be build stand-alone)
> > - Reflection (can't be build stand-alone)
> > - session (what's a webserver without sessions?)
> > - SPL (can't be build stand-alone)
> > - standard (for obvious reasons)
> > - xml (required for pear building. Should be turned into a module once 
> > something like phpctl is in place)
> > - zlib (required for phar)
> > 
> > When updating to the new packages I didn't encounter any problems, 
> > except for the expected behaviour that some modules or SAPIs are now in 
> > other packages, which could easily be 

Re: UPDATE: php revamp

[Stuart Henderson]

On 2017/07/02 19:52, Martijn van Duren wrote:
> - Move modules to their own subpackage where possible. I don't like my 
> clean php install having ftp or wddx. Let people make up their own mind.

Doing this means that it's necessary to audit the existing ports
using PHP to figure out which of them need extra dependencies.

Re: UPDATE: php revamp

[Robert Nagy]

Hi

Antoine, can you please push this into a bulk?

On (2017-07-02 19:52), Martijn van Duren wrote:
> Hello ports@,
> 
> Last couple of months I've been busy getting to know the OpenBSD ports 
> system and the php build environment.
> The main reason being my need for functionality at my $DAYJOB which 
> isn't offered by the default php install on OpenBSD. Most notably php 
> 7.1 and chroot (the php function).
> 
> During my quest I ended up touching about every part of the port and 
> I'm currently quite happy with the result, although there's still some 
> things I want to touch later on.
> 
> Some of the highlights I've done:
> - Remove PHP 5.5. It's dead upstream for almost a year, so there's no 
> need to keep it on OpenBSD.
> - Clean up the CONFIGURE_ARGS. There were some arguments there that 
> were simply not in PHP anymore.
> - Move some deprecated modules into the PHP 5.6 Makefile. This keeps 
> the Makefile.inc cleaner of if/else bloat.
> - Replace the -fastcgi port with -cgi. -cgi is the official name and 
> for fastcgi needs -fpm is recommended. This avoids confusion.
> - Move modules to their own subpackage where possible. I don't like my 
> clean php install having ftp or wddx. Let people make up their own mind.
> - Remove unused dependencies (e.g. mariadb isn't needed when building 
> with mysqlnd)
> - Move every SAPI to their own subpackage. People running -fpm don't 
> need mod_php or -cgi.
> - Move the extension headers to their corresponding subpackage.
> - Clean up the build environment. YACC=, USE_LIBTOOL, etc don't seem to 
> be needed (anymore).
> - Clean up patches. Some are unneeded, redundant, superfluous so keep 
> it to a minimum for maintainability.
> - Subpackages requiring another module have those dependencies. (e.g. 
> installing -pdo_mysql also pulls in -pdo and -mysqlnd)
> - Install phar and disable it on sparc64. This should allow us to have 
> php on sparc64, without phar support. Untested for lack of hardware.
> - Enable the chroot function by default. This function normally gets 
> disabled if any SAPI other than -cli, -cgi, or -embed is compiled.
> I reckon that if the chroot function is usable the code is running as 
> root and you have bigger problems than a php server locking itself out 
> of your main filesystem.
> - Allow phpize to work without --with-php-config.
> - Try to rely on other packages where code would be otherwise compiled 
> in. E.g. devel/pcre for the pcre module and textproc/oniguruma for 
> mbstring. These libraries are also packaged inside PHP if not available
> on the main system.
> - Miscellaneous cleanup
> 
> For the packages this means the following:
> Removed:
> - php-fastcgi
> Added:
> - php-apxs2
> - php-bcmath
> - php-calendar
> - php-cgi
> - php-cli
> - php-ctype
> - php-dom
> - php-enchant
> - php-exif
> - php-fileinfo
> - php-fpm
> - php-ftp
> - php-gettext
> - php-iconv
> - php-json
> - php-mbstring
> - php-mysqlnd
> - php-opcache
> - php-pdo
> - php-pdo_sqlite
> - php-phar
> - php-posix
> - php-readline
> - php-simplexml
> - php-sockets
> - php-sqlite3
> - php-sysvmsg
> - php-sysvsem
> - php-sysvshm
> - php-tokenizer
> - php-wddx
> - php-xmlreader
> - php-xmlwriter
> Modules moved to shared components:
> - bcmath
> - calendar
> - ctype
> - dom
> - exif
> - fileinfo
> - ftp
> - gettext
> - iconv
> - json
> - mbstring
> - mysqlnd
> - PDO
> - pdo_sqlite
> - Phar
> - posix
> - readline
> - SimpleXML
> - sockets
> - sqlite3
> - sysvmsg
> - sysvsem
> - sysvshm
> - tokenizer
> - wddx
> - xmlreader
> - xmlwriter
> Modules kept compiled in:
> - Core (for obvious reasons)
> - date (can't be build stand-alone)
> - ereg (removed in php 7.0, not worth the effort, also pcre is in 
> default install)
> - filter (can't be build stand-alone)
> - hash (required to be built-in for phar hash-checking)
> - libxml (can't be build stand-alone)
> - openssl (allow tls as a Stream Socket Transport in a default install)
> - pcre (can't be build stand-alone)
> - Reflection (can't be build stand-alone)
> - session (what's a webserver without sessions?)
> - SPL (can't be build stand-alone)
> - standard (for obvious reasons)
> - xml (required for pear building. Should be turned into a module once 
> something like phpctl is in place)
> - zlib (required for phar)
> 
> When updating to the new packages I didn't encounter any problems, 
> except for the expected behaviour that some modules or SAPIs are now in 
> other packages, which could easily be covered with a current.html entry.
> 
> Some things that I would like to realize once this gets accepted are:
> - Allow easier module manipulation via an external tool. E.g. 
> "phpctl-5.6 enable pdo_mysql", or "phpctl-5.6 list | phpctl-7.1 load".
> I'm not sure of the semantics and haven't started on this yet. But it
> would solve some issues, like migration or automatic module enabling
> during package building (-xml).
> - Allow pecl modules to be built with multiple PHP versions. Right now 
> all pecl modules are