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

[Flowdalic]

No description provided.

[mgorny]

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]

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

• kernels-computed.d
• kernel-sets-computed.d
• kernels-determined.d
• kernel-sets-determined.d

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

[Flowdalic]

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

[Flowdalic]

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

[Flowdalic]

@mgorny friendly ping :)

[mgorny]

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]

@mgorny friendly ping

[mgorny]

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]

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: Note that for my use case, this information is not required.

[mgorny]

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).