* [gentoo-dev] default php-ext status @ 2024-04-22 14:46 Jaco Kroon 2024-04-22 16:49 ` Michael Orlitzky 0 siblings, 1 reply; 4+ messages in thread From: Jaco Kroon @ 2024-04-22 14:46 UTC (permalink / raw) To: gentoo development Hi All, For PHP modules that's getting installed, by default they all link ext/${modulename}.ini into ext-active/ such that all modules by default is active for all SAPIs. Short of INSTALL_MASK, is there way to better control for sysadmins? If I rm the symlinks, on next remerge they restore themselves: plastiekpoot [16:43:09] /etc/php (master) # ls -lah */ext-active/xdebug.ini lrwxrwxrwx 1 root root 17 Apr 22 15:36 apache2-php8.1/ext-active/xdebug.ini -> ../ext/xdebug.ini lrwxrwxrwx 1 root root 17 Apr 22 15:36 cli-php8.1/ext-active/xdebug.ini -> ../ext/xdebug.ini lrwxrwxrwx 1 root root 17 Apr 22 15:36 fpm-php8.1/ext-active/xdebug.ini -> ../ext/xdebug.ini plastiekpoot [16:43:15] /etc/php (master) # rm apache2-php8.1/ext-active/xdebug.ini plastiekpoot [16:43:21] /etc/php (master) # emerge -av xdebug ... plastiekpoot [16:43:52] /etc/php (master) # ls -lah */ext-active/xdebug.ini lrwxrwxrwx 1 root root 17 Apr 22 16:43 apache2-php8.1/ext-active/xdebug.ini -> ../ext/xdebug.ini lrwxrwxrwx 1 root root 17 Apr 22 16:43 cli-php8.1/ext-active/xdebug.ini -> ../ext/xdebug.ini lrwxrwxrwx 1 root root 17 Apr 22 16:43 fpm-php8.1/ext-active/xdebug.ini -> ../ext/xdebug.ini Which in my *opinion* is not desirable behaviour, but I'm open for discussion. xdebug.mode = off by default, but the extension still gets loaded. Not sure if there is a sensible "solution", further expanding USE flags certainly is not a desirable option, so perhaps INSTALL_MASK (per-package env) is the best solution ... ? Kind regards, Jaco ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-dev] default php-ext status 2024-04-22 14:46 [gentoo-dev] default php-ext status Jaco Kroon @ 2024-04-22 16:49 ` Michael Orlitzky 2024-04-23 11:05 ` Jaco Kroon 0 siblings, 1 reply; 4+ messages in thread From: Michael Orlitzky @ 2024-04-22 16:49 UTC (permalink / raw) To: gentoo-dev On Mon, 2024-04-22 at 16:46 +0200, Jaco Kroon wrote: > > Which in my *opinion* is not desirable behaviour, but I'm open for > discussion. > > xdebug.mode = off by default, but the extension still gets loaded. > > Not sure if there is a sensible "solution", further expanding USE flags > certainly is not a desirable option, so perhaps INSTALL_MASK > (per-package env) is the best solution ... ? You can replace the symlinks with empty files. The package manager should then refuse to overwrite them. It _looks_ wrong (why are these non-active extensions in ext-active?), but it's the easiest solution. I think the default should be for the extensions to be per-SAPI disabled and for users to enable them by creating the symlinks. (The "ext" and "ext-active" design screams this.) That would be an easy change to php-ext-source-r3.eclass but risks breaking everyone's web servers if we do it without news items and/or ewarnings. There's nobody in the PHP project at the moment. If you want to make an -r4 of the eclass and handle the paperwork, by all means... ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-dev] default php-ext status 2024-04-22 16:49 ` Michael Orlitzky @ 2024-04-23 11:05 ` Jaco Kroon 2024-04-25 12:27 ` Michael Orlitzky 0 siblings, 1 reply; 4+ messages in thread From: Jaco Kroon @ 2024-04-23 11:05 UTC (permalink / raw) To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 3663 bytes --] Hi, On 2024/04/22 18:49, Michael Orlitzky wrote: > On Mon, 2024-04-22 at 16:46 +0200, Jaco Kroon wrote: >> Which in my *opinion* is not desirable behaviour, but I'm open for >> discussion. >> >> xdebug.mode = off by default, but the extension still gets loaded. >> >> Not sure if there is a sensible "solution", further expanding USE flags >> certainly is not a desirable option, so perhaps INSTALL_MASK >> (per-package env) is the best solution ... ? > You can replace the symlinks with empty files. The package manager > should then refuse to overwrite them. It _looks_ wrong (why are these > non-active extensions in ext-active?), but it's the easiest solution. > > I think the default should be for the extensions to be per-SAPI > disabled and for users to enable them by creating the symlinks. (The > "ext" and "ext-active" design screams this.) That would be an easy > change to php-ext-source-r3.eclass but risks breaking everyone's web > servers if we do it without news items and/or ewarnings. eselect php-ext perhaps?Both to configure the defaults for new modules/sapi/version kind of thing (perhaps layered), and then hook into that from the eclass? > There's nobody in the PHP project at the moment. If you want to make an > -r4 of the eclass and handle the paperwork, by all means... What?!? Surprise! Wish I had capacity for volunteering more time. Happy to do drive-by's for PHP stuff we use, but definitely not in a position to "be the project" kind of thing. Perhaps I can start off on an eselect-php-extensions package (or expand eselect-php?), and once at least one other party is happy with the *UI* component and how that works, we can update the eclass to use that rather than blindly installing the symlinks? eselect php-ext list [version] eselect php-ext enable {extension} [version] [sapi] eselect php-ext disable {extension} [version] [sapi] Where we have one "special extention" called _default_ and one special version called "all" (and sapi "all"). These shall be used for any tuple for which there is no explicit configuration, so for any specific (pkg, version, sapi) tuple we check in this order for available configs: 1. (pkg, version, sapi) 2. (pkg, all, sapi) 3. (pkg, version, all) 4. (pkg, all, all) 5-8. repeat of 1-4 but with _default_. It's unclear what the preferred order for 2,3 should be, however, based on our requirements sapi should take priority over version as this will be the most common enable/disable in my experience. Once that works, then eclass updates such that eclass doesn't install any symlinks for ext-active/ as part of pkg_install. postinstall in eclass enumerates the relevant php versions for which the package was installed, along with sapi's and check which symlinks should be created. prerm does opposite (assuming we're not replacing a version, since I believe postinstall would invoke prior to the old version's prerm?). Possibly easier to just not remove symlinks in prerm but provide a eselect php-ext cleanup which will cleanup broken symlinks in /etc/php in postrm? Also, a way to cleanup the stored configuration for enabled/disabled. eclass maintains current behaviour if eselect-php-extensions is not installed (which may become a requirement later, but how do we handle users making manual additions/modifications to /etc/php/ or have some form of "fsck" for that?) SLOT'ing here may require some careful handling since for example pecl-parallel had a version for php7* (pecl-parallel 1.1.*) and another fo php8* (1.2.*). Don't think this is undo-able but it'll be a first for me so may be a few rounds of back&forth. Kind regards, Jaco [-- Attachment #2: Type: text/html, Size: 4750 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-dev] default php-ext status 2024-04-23 11:05 ` Jaco Kroon @ 2024-04-25 12:27 ` Michael Orlitzky 0 siblings, 0 replies; 4+ messages in thread From: Michael Orlitzky @ 2024-04-25 12:27 UTC (permalink / raw) To: gentoo-dev On Tue, 2024-04-23 at 13:05 +0200, Jaco Kroon wrote: > but how do we handle > users making manual additions/modifications to /etc/php/ or have some > form of "fsck" for that?) We'd have to use a new location that doesn't collide with anything that the user might edit, like /etc/php/*/ext-eselect, the contents of which would then be included into the active config. The rest of the design sounds reasonable, but I would caution you to take it one step at a time. For now, managing extensions is a matter of editing one-line text files under /etc. They can be stored in git and don't require any special tooling. Updates are protected by CONFIG_PROTECT. Aside from the issue that started this thread, it works pretty well. Having an eselect-foo that is tied to certain versions of packages is no fun. To some extent, eselect-php is like this. If we want to add a new major version of php, eselect-php needs to know about it. Conversely, if we want to change some aspect of eselect-php, then all versions of php need to tolerate it. You can put blockers in the ebuilds, or maintain compatibility until it's no longer needed (years, for PHP), but no matter what you do it's more work than if you didn't have to do it. In any case, the default for the eclass will have to switch to extensions being off-by-default. If you want to dive in to this, I would suggest doing that first, and then giving it a month or so to decide whether or not you still care. IMO writing a new eselect script will be a lot of work for a little gain at that point. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-04-25 12:27 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-04-22 14:46 [gentoo-dev] default php-ext status Jaco Kroon 2024-04-22 16:49 ` Michael Orlitzky 2024-04-23 11:05 ` Jaco Kroon 2024-04-25 12:27 ` Michael Orlitzky
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox