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
