From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 621801581E7 for ; Tue, 23 Apr 2024 11:06:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 15E52E29EB; Tue, 23 Apr 2024 11:05:58 +0000 (UTC) Received: from uriel.iewc.co.za (uriel.iewc.co.za [IPv6:2c0f:f720:0:3::9a49:2248]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7275EE29E4 for ; Tue, 23 Apr 2024 11:05:56 +0000 (UTC) Received: from [154.73.32.4] (helo=tauri.local.uls.co.za) by uriel.iewc.co.za with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1rzDyE-000000007Th-0Lgw for gentoo-dev@lists.gentoo.org; Tue, 23 Apr 2024 13:05:54 +0200 Received: from [192.168.42.21] by tauri.local.uls.co.za with esmtp (Exim 4.97.1) (envelope-from ) id 1rzDyC-000000006rT-2F4Z for gentoo-dev@lists.gentoo.org; Tue, 23 Apr 2024 13:05:52 +0200 Content-Type: multipart/alternative; boundary="------------Jlrq7gJdASdSBaQIRzSlZxf2" Message-ID: <6bec8c67-e463-44c9-a009-619325dffe20@uls.co.za> Date: Tue, 23 Apr 2024 13:05:52 +0200 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [gentoo-dev] default php-ext status To: gentoo-dev@lists.gentoo.org References: <4f932586b3fb34a202d53ede4b0da30976074ddd.camel@gentoo.org> Content-Language: en-GB From: Jaco Kroon Autocrypt: addr=jaco@uls.co.za; keydata= xsBNBFXtplYBCADM6RTLCOSPiclevkn/gdf8h9l+kKA6N+WGIIFuUtoc9Gaf8QhXWW/fvUq2 a3eo4ULVFT1jJ56Vfm4MssGA97NZtlOe3cg8QJMZZhsoN5wetG9SrJvT9Rlltwo5nFmXY3ZY gXsdwkpDr9Y5TqBizx7DGxMd/mrOfXeql57FWFeOc2GuJBnHPZQMJsQ66l2obPn36hWEtHYN gcUSPH3OOusSEGZg/oX/8WSDQ/b8xz1JKTEgcnu/JR0FxzjY19zSHmbnyVU+/gF3oeJFcEUk HvZu776LRVdcZ0lb1bHQB2K9rTZBVeZLitgAefPVH2uERVSO8EZO1I5M7afV0Kd/Vyn9ABEB AAHNG0phY28gS3Jvb24gPGphY29AdWxzLmNvLnphPsLAdwQTAQgAIQUCVe2mVgIbAwULCQgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRAILcSxr/fungCPB/sHrfufpRbrVTtHUjpbY4bTQLQE bVrh4/yMiKprALRYy0nsMivl16Q/3rNWXJuQ0gR/faC3yNlDgtEoXx8noXOhva9GGHPGTaPT hhpcp/1E4C9Ghcaxw3MRapVnSKnSYL+zOOpkGwye2+fbqwCkCYCM7Vu6ws3+pMzJNFK/UOgW Tj8O5eBa3DiU4U26/jUHEIg74U+ypYPcj5qXG0xNXmmoDpZweW41Cfo6FMmgjQBTEGzo9e5R kjc7MH3+IyJvP4bzE5Paq0q0b5zZ8DUJFtT7pVb3FQTz1v3CutLlF1elFZzd9sZrg+mLA5PM o8PG9FLw9ZtTE314vgMWJ+TTYX0kzsBNBFXtplYBCADedX9HSSJozh4YIBT+PuLWCTJRLTLu jXU7HobdK1EljPAi1ahCUXJR+NHvpJLSq/N5rtL12ejJJ4EMMp2UUK0IHz4kx26FeAJuOQMe GEzoEkiiR15ufkApBCRssIj5B8OA/351Y9PFore5KJzQf1psrCnMSZoJ89KLfU7C5S+ooX9e re2aWgu5jqKgKDLa07/UVHyxDTtQKRZSFibFCHbMELYKDr3tUdUfCDqVjipCzHmLZ+xMisfn yX9aTVI3FUIs8UiqM5xlxqfuCnDrKBJjQs3uvmd6cyhPRmnsjase48RoO84Ckjbp/HVu0+1+ 6vgiPjbe4xk7Ehkw1mfSxb79ABEBAAHCwF8EGAEIAAkFAlXtplYCGwwACgkQCC3Esa/37p7u XwgAjpFzUj+GMmo8ZeYwHH6YfNZQV+hfesr7tqlZn5DhQXJgT2NF6qh5Vn8TcFPR4JZiVIkF o0je7c8FJe34Aqex/H9R8LxvhENX/YOtq5+PqZj59y9G9+0FFZ1CyguTDC845zuJnnR5A0lw FARZaL8T7e6UGphtiT0NdR7EXnJ/alvtsnsNudtvFnKtigYvtw2wthW6CLvwrFjsuiXPjVUX 825zQUnBHnrED6vG67UG4z5cQ4uY/LcSNsqBsoj6/wsT0pnqdibhCWmgFimOsSRgaF7qsVtg TWyQDTjH643+qYbJJdH91LASRLrenRCgpCXgzNWAMX6PJlqLrNX1Ye4CQw== Organization: Ultimate Linux Solutions (Pty) Ltd In-Reply-To: <4f932586b3fb34a202d53ede4b0da30976074ddd.camel@gentoo.org> X-Spam-report: Relay access (uriel.iewc.co.za). X-Archives-Salt: e7af35c1-2609-4f5a-ba48-e79ff5e5cd75 X-Archives-Hash: d0ef5a48a38ef7fbae4d9b61084442a8 This is a multi-part message in MIME format. --------------Jlrq7gJdASdSBaQIRzSlZxf2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 --------------Jlrq7gJdASdSBaQIRzSlZxf2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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

--------------Jlrq7gJdASdSBaQIRzSlZxf2--