On 2025-06-15 at 04:01, tomas@tuxteam.de wrote:
> On Sun, Jun 15, 2025 at 09:31:45AM +0200, Anders Andersson wrote:
>
>> On Sun, Jun 15, 2025 at 7:45 AM Nicholas Geovanis
>> <nickgeovanis@gmail.com> wrote:
>>> You could easily do this with ansible. In perhaps 30 lines of
>>> YAML you could install those fixes, and do the grub work in the
>>> same ansible source file. Repeatable the next time you have fixes
>>> to install, just run that playbook again with 1 command.
>>
>> First of all, 30 lines to automate 2-4 lines is absurd. You have a
>> hammer, don't recommend it to people who need a screwdriver!
>
> OK, here is the screwdriver (from man apt.conf(5)):
>
> Pre-Invoke, Post-Invoke
> This is a list of shell commands to run before/after
> invoking dpkg(1). Like options this must be specified
> in list notation. The commands are invoked in order
> using /bin/sh; should any fail APT will abort.
>
> (Those are in the DPkg section, so probably their full name is
> DPkg::Post-Invoke, etc).
That's for running (before/)after *every* dpkg invocation (within apt),
though, isn't it? By my read, the OP was looking for something which
would run *only when grub has been updated as part of the invocation*.
Unless there's some way for the command being run to receive information
about the dpkg session involved (in which case this would boil down to
"write a shell script and use that as the command"), or a way for a
command running independent of apt to *detect* whether such an update
has happened, that doesn't look like it would satisfy the need.
I know there are ways for one package to react to the update of another,
via dpkg triggers. I don't know whether such a trigger has to be defined
in the package being updated ("I provide a man page, so tell any package
interested in man pages to do its thing") or in the package reacting
("any time a package referencing a file under this path is updated, tell
me").
If it's the former, then unless grub already defines a trigger which
other packages could react to, I don't hae any ideas offhand. If it's
the latter, then in principle it seems like it should be possible to
create a local dummy package which defines a trigger against (some key
element contained within) grub, and then in response to that trigger
would run a script which does what the OP currently does manually.
That would put you in the domain of package creation, however, unless
equivs has some ability to help dealing with triggers (which I don't see
in a glance at its man page). I have *some* degree of experience in that
context, but not much, and none of it involves how triggers are arranged.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature