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.
