On 2023-08-21 12:00:18, Ulrich Mueller wrote:
In addition to user patches, you can also put your own modules in the
${HOME}/.eselect/modules/ directory.
For example, you could either copy kernel.eselect to there and modify
it. Or, you could have a mykernel.eselect module, along these lines:
I did consider doing so, however with that approach my effective fork of
the kernel.eselect module would get continually outdated, while a
wrapper module requires a different command and isn't very expressive on
what it is, making future maintenance harder. The wrapper would also be
a lot of boilerplate, having to mention all actions, not just modified
ones. Both solutions didn't feel right to me.
I expect to use and modify eselect more in the future, and want an
approach that scales well while being low maintenance. A patch is the
correct solution for me, whether it gets upstreamed or not.
Also, by design, eselect itself doesn't rely on any configuration in
/etc so this would be a somewhat intrusive change.
> # l /etc/eselect/
> total 4.0K
> drwxr-xr-x 1 root root 48 2023-08-15 19:59:07 .
> drwxr-xr-x 1 root root 3.0K 2023-08-21 12:07:30 ..
> drwxrwxr-x 1 root root 12 2023-08-15 19:59:31 hooks
> -rw-r--r-- 1 root root 1.6K 2023-05-19 16:57:34 repository.conf
> drwxr-xr-x 1 root root 120 2023-08-10 03:09:50 wine
This is what my /etc/eselect dir looks like right now. I have hardly
used eselect in the past, and my system is fairly recent.
Given the apparent existing practice of putting eselect related elements
into /etc/eselect and that the hooks are entirely optional, I see no
difference to what has already been established.
Without knowledge of the feature, the directory doesn't exist and no
action is ever taken.
When someone hears of and intends to use the hooks, they create the
correct directory structure.
As a side note, your previously posted patch wouldn't work as-is:
- ${function} "$@"
+ ${function} "${params}"
Using a scalar variable instead of "$@" (which is an array) would break
quite a few modules.
Thanks, I did not know that. The updated patch below should handle those
cases now.
--- a/libs/core.bash.in
+++ b/libs/core.bash.in
@@ -20,10 +20,24 @@
-check_do() {
+check_do() {
local function=$1
- shift
+ shift; params=("${@}")
if is_function "${function}" ; then
+ run_hook "${ESELECT_MODULE_NAME}" "${function##do_}" pre
- ${function} "$@"
+ ${function} "${params[@]}"
+ run_hook "${ESELECT_MODULE_NAME}" "${function##do_}" post
else
die "No function ${function}"
fi
}
+# Redjard patch: call hooks
+run_hook() {
+ local action=$1
+ local subaction=$2
+ local hookscriptdir=$3
+ for hookfile in
"/etc/eselect/hooks/${action}/${subaction}/${hookscriptdir}"/* ; do [[
+ `basename "$hookfile"` =~ ^[a-zA-Z0-9_-][a-zA-Z0-9._-]+$
+ ]] &&
+ source "$hookfile"
+ done
+}
+
