[prev in list] [next in list] [prev in thread] [next in thread]
List: gentoo-dev
Subject: Re: [gentoo-dev] Add Hooks to Eselect
From: konsolebox <konsolebox () gmail ! com>
Date: 2023-08-22 2:36:02
Message-ID: CAJnmqwbqwqdG=YHi0MAhuNwRJyj8vWT_KLQXtDLGR7bxaer42A () mail ! gmail ! com
[Download RAW message or body]
On Tue, Aug 22, 2023, 02:50 Ulrich Mueller, <ulm@gentoo.org> wrote:
> >>>>> On Mon, 21 Aug 2023, konsolebox wrote:
>
> > This actually allows users to virtually extend an eselect module without
> > needing to fork it. The things people can do are endless.
>
> This isn't what eselect modules were designed for. They are specialised
> tools that are supposed to do one thing, and one thing only.
So let's say modules weren't initially designed to be extensive. What's
stopping those from becoming one now? Tradition?
It's like
> suggesting that a command like cat or mv would need configuration or
> some extension mechanism.
>
Bad comparison and a stretch.
Also, given that eselect modules are normally run as root and the damage
> that can result from bugs, I'd rather keep things simple, instead of
> introducing "endless" possibilities. This approach has worked very well
> during the last 18 years.
>
And when I said unnecessary restriction this was it. You're trying to
restrict what users can do in a free system like Gentoo because they might
damage their system which is ridiculous.
If you want to keep things simple for yourself don't touch
/etc/eselect/hooks.
And if you think third party code might abuse it, QA it. Or maybe just
make eselect read /usr/local/etc/eselect/hooks instead.
> (If anything, a hook mechanism would look very different from what was
> proposed here. First, changing a low-level function like check_do() is
> really a no-no, because this function is documented in the eselect
> developer guide and third-party modules may rely on it. Second, instead
> of executing a separate script for every hook, there would be a file
> defining shell functions for all subactions of a given module. But I
> haven't thought about any details, because as I said, I don't see much
> incentive for such a thing.)
>
I just checked. Check_do is currently documented to be only used
internally so no modules should use it but if you really think check_do
shouldn't be modified then the answer is simple. Just make the function
that calls the hooks the wrapper instead.
As for declaring functions to represent as hooks yes I thought about that
but that's a terrible idea. Not only is it hard to declare declaratively
it also taints eselect's environment.
Come think of it, hooks should be source'd from a subshell. I.e., "(
source ... )".
>
[Attachment #3 (text/html)]
<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On \
Tue, Aug 22, 2023, 02:50 Ulrich Mueller, <<a href="mailto:ulm@gentoo.org" \
rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" \
target="_blank">ulm@gentoo.org</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">>>>>> On Mon, 21 Aug 2023, konsolebox \
wrote:<br> <br>
> This actually allows users to virtually extend an eselect module without<br>
> needing to fork it. The things people can do are endless.<br>
<br>
This isn't what eselect modules were designed for. They are specialised<br>
tools that are supposed to do one thing, and one thing \
only.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">So let's \
say modules weren't initially designed to be extensive. What's stopping \
those from becoming one now? Tradition?</div><div dir="auto"><br></div><div \
dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 \
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's like<br> suggesting that \
a command like cat or mv would need configuration or<br> some extension \
mechanism.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Bad \
comparison and a stretch.</div><div dir="auto"><br></div><div dir="auto"><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> Also, given that eselect modules \
are normally run as root and the damage<br> that can result from bugs, I'd rather \
keep things simple, instead of<br> introducing "endless" possibilities. \
This approach has worked very well<br> during the last 18 \
years.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">And when \
I said unnecessary restriction this was it. You're trying to restrict what \
users can do in a free system like Gentoo because they might damage their system \
which is ridiculous.</div><div dir="auto"><br></div><div dir="auto">If you want to \
keep things simple for yourself don't touch /etc/eselect/hooks.</div><div \
dir="auto"><br></div><div dir="auto">And if you think third party code might abuse \
it, QA it. Or maybe just make eselect read /usr/local/etc/eselect/hooks \
instead.</div><div dir="auto"><br></div><div dir="auto"><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br> (If anything, a hook mechanism \
would look very different from what was<br> proposed here. First, changing a \
low-level function like check_do() is<br> really a no-no, because this function is \
documented in the eselect<br> developer guide and third-party modules may rely on it. \
Second, instead<br> of executing a separate script for every hook, there would be a \
file<br> defining shell functions for all subactions of a given module. But I<br>
haven't thought about any details, because as I said, I don't see much<br>
incentive for such a thing.)<br></blockquote></div></div><div \
dir="auto"><br></div><div dir="auto">I just checked. Check_do is currently \
documented to be only used internally so no modules should use it but if you really \
think check_do shouldn't be modified then the answer is simple. Just make the \
function that calls the hooks the wrapper instead.</div><div \
dir="auto"><br></div><div dir="auto">As for declaring functions to represent as hooks \
yes I thought about that but that's a terrible idea. Not only is it hard to \
declare declaratively it also taints eselect's environment.</div><div \
dir="auto"><br></div><div dir="auto">Come think of it, hooks should be source'd \
from a subshell. I.e., "( source ... )".</div><div dir="auto"><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic