search

projg2 / eclean-kernel

Installed kernel cleanup tool
GNU General Public License v2.0
31 stars 10 forks source link

Add support for /etc/eclean-kernel/hook.d hooks #38

Closed Flowdalic closed 1 year ago

mgorny commented 1 year ago

One last idea — let's rename hook.d to something that better indicates that it takes place after preparing the kernel list. I'd normally expect hooks to be run after removals. I was thinking of pre-removal.d but it's also run when no removals are planned, so maybe there's a better name.

Flowdalic commented 1 year ago

I was thinking of pre-removal.d but it's also run when no removals are planned, so maybe there's a better name.

ATM, the last one is what I like the most. But I have no strong opinion here. Let me know what you think.

Flowdalic commented 1 year ago

Went with kernel-sets-determined.d, but I am happy to change it to anything you like.

Flowdalic commented 1 year ago

Went with post-kernel-sets.d. I think the post- prefix makes it more obvious that it is a directory for hooks.

Flowdalic commented 1 year ago

@mgorny friendly ping :)

mgorny commented 1 year ago

I'm sorry, I need to think about the name a little more. I really want it to be "obvious" when it runs, and how many times, and in what circumstances.

Flowdalic commented 1 year ago

@mgorny friendly ping

mgorny commented 1 year ago

I'm sorry but I can't think of a really good way of doing this right at the moment.

How about if I added a machine-readable output mode that you could use with --pretend (or just with removal), and grab from a wrapper to do your bidding?

Flowdalic commented 1 year ago

That feels like an unnecessary complication. I am not sure what the advantage would be, while it would mean to loose the direct hook capability (incl. having multiple hooks). I like the current design.

I am also not sure if I understand the concerns you have with the current approach. But would having an environment variable, e.g., ECLEAN_PRETEND, which signals if a removal action is to be performed or not, mitigate your concerns? Since you wrote "I really want it to be `'obvious' when it runs".1

1: Note that for my use case, this information is not required.

mgorny commented 1 year ago

Unnecessary complication is adding semi-generic hook support with one kind of hooks that's designed ad-hoc to implement a hack to add unsupported functionality without clear design how to go from there, how to make hooks that are actually useful and quite good probability that extending hook support will require rewriting the hook running code to support different kinds of hooks and different behavior (per-kernel hooks, feedback).