Re: [gentoo-dev] default php-ext status

[Michael Orlitzky <mjo@gentoo.org>]

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.