Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#59317 - [pacman] Way to pass operation to hook Exec script

Attached to Project: Pacman
Opened by AMM (amish) - Friday, 13 July 2018, 02:03 GMT
Last edited by Eli Schwartz (eschwartz) - Friday, 13 July 2018, 02:51 GMT
Task Type Feature Request
Category General
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version 5.1.0
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Summary and Info:
I would like to request for a feature for hook processing.

A way to pass "operation" to Exec script

This can be either as parameter or via environment variable.

[Trigger]
Operation = Install
Operation = Upgrade
Operation = Remove
...

[Action]
When = PostTransaction
# Option 1: set $ENV{"_PACMAN_OPERATION"} before calling
# Option 2: allow %format parameter parsing
Exec = hook-script %OP ...

This way single script can handle multiple operation and it can help reduce code redundancy.

Option 1 should be easier to implement
Option 2 may require parsing of Exec line and search / replace format codes.

Please consider. Thank you.
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Friday, 13 July 2018, 02:51 GMT
Reason for closing:  Won't implement
Comment by Eli Schwartz (eschwartz) - Friday, 13 July 2018, 02:50 GMT
Sort of like this?

$ cat /usr/share/libalpm/hooks/70-dkms-install.hook
[Trigger]
Operation = Install
Operation = Upgrade
Type = File
Target = usr/src/*/dkms.conf
Target = usr/lib/modules/*/build/include/
Target = usr/lib/modules/*/modules.alias

[Action]
Description = Install DKMS modules
Depends = dkms
When = PostTransaction
Exec = /usr/lib/dkms/alpm-hook install
NeedsTargets
$ cat /usr/share/libalpm/hooks/70-dkms-remove.hook
[Trigger]
Operation = Upgrade
Operation = Remove
Type = File
Target = usr/src/*/dkms.conf
Target = usr/lib/modules/*/build/include/
Target = usr/lib/modules/*/modules.alias

[Action]
Description = Remove DKMS modules
Depends = dkms
When = PreTransaction
# SIGPIPE workaround. See  FS#49816 
#Exec = /usr/lib/dkms/alpm-hook remove
Exec = /usr/bin/perl -e "$SIG{PIPE}='DEFAULT'; exec('/usr/lib/dkms/alpm-hook', 'remove');"
NeedsTargets


Oh wait, the description is different anyway, so the hook is hardly reusable...

This is on top of the fact that you actually want a hook that does completely different things depending on how it is called, which I'd say is an anti-feature.

Hooks are so few lines of code in the first place, there really is nothing to be gained by allowing you to combine totally different things into one hook file, and in the process make it much more complicated for no actual gain, and less descriptive effects.

Just write out your second "code redundant" 4-line ini file (not counting 2 boilerplate section headers and 2 binary choices) with its 3 and possibly more non-redundantly different values.

Loading...