> On Jan 26, 2024, at 12:12 PM, Luca Pizzamiglio <pizza...@freebsd.org> wrote: > > Hi Alexander. > > You understand correctly what I wrote: > * Several master/slave ports can be converted to use subpackages. > * Php is a potential candidate for subpackage adoption > However, I wasn't explicit on the fact that I won't impose subpackages > adoption on anyone. > Specifically, I don't want to convert php into subpackages right away, there > are smaller/easier examples to tackle first. > And in general, the maintainer is the one making the decision, and they can > disagree with me. > An experimental adoption will be considered for lang/php83, existing versions > won't be converted. > > As you pointed out, there are two challenges specifically for php: > * moving all extensions (slave ports) to subpackages in lang/php* can > significantly increase build times (for ports users) and its dependency list > (for pkg users) > * the meta php-extensions port is a convenient way create a custom group of > extensions > Php port could be converted into subpackages if and only if we can provide a > similar experience as before. > To do that: > * we would need to add options to enable/disable extensions, in order to > manage build times and dependencies > * we need to provide the similar meta php-extensions package, as it's largely > used > > If the maintainer finds out that subpackages are not suitable for php, they > won't be adopted. > > Best regards, > pizzamig >
Hi Everyone, Comments are in point of me being the php maintainer: It's not that I haven't checked it yet about the possibility of converting php ports to subpkgs but there are some issues. Not all extensions can be converted to subpkg and there will be some pkgs left out as standard pkgs. So for example there will be a mix of # pkg install php83~opcache and # pkg install php83-xmlrpc Which is a mix of both worlds and will be a real pain point as we have to memorize which was where. Although there is a php8X-extensions package but not always everyone uses that. It's just sort of a meta pkg which installs a group of pkg. But at least this pkg is not at all advised by me although it helps to install couple of extensions in one go. Noone should have extra extensions installed in a system without any reason. At least I have been B enough not to have it available in the work environment and developers install the extensions individually. About build time I would like to say also inline with ale@. No shared codes are actually rebuilt during the build of other extensions. The only target that happens to be repetitive is installing php itself. And extract target is also carefully crafted to extract only the related files. And contrary to other ports not only I have to play with the ports itself but also in the php.mk. :'( Will I convert php to subpkg? Not at this point. For the sake of sanity and maintenance in php.mk my options are either php81 or php83 at this point. php81 is going to be removed in a year so no point in investing time on that. php83 is being used in production at my workplace and means that I have to also update another 200 hosts and fix some corner cases at my work place which I do not want to do atm. So most probably in the coming months when php 8.4 or 9.0 is released I will give it another try with a fresh look rather than existing codebase of the ports itself. For now everything is good in php world. :) Although there are lots of other places for playing around with subpkg and I will do so if I find suitable candidates. Kind regards, Moin(bofh@ with all hats off)
signature.asc
Description: Message signed with OpenPGP
