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.
