Closed recolic closed 6 years ago
Yes for general workarounds and stuff like that is fine
I have little-to-no experience with archlinux hooks and know nothing about yaourt's internals, so I could be mistaken. But, from what I can tell, you plan for hooks to be plain executable scripts called at appropriate times during the installation process. If so, this seems quite a bit different from libalpm hooks, and should probably not be associated with any of its directories.
Also, I believe you are currently only looking for hooks in /usr. This directory is intended to hold application/distro provided data, and is not intended to be edited on end systems (Filesystem Hierarchy Standard ). Thus you need a different directory if end users should be able to create their own hooks. Consider changing to or adding additional support for user-hooks (somewhere in $HOME/) and/or systemwide-hooks (somewhere in /etc).
Since these hooks seem to be application specific (intended for automating patching?), for what I think is is intended to be used for, I believe it belongs in the users home directory.
I originally thought this might be for yaourt specific libalpm hook equivalent, or some other non-package specific hooks. But it seems like this is intended more-so for patching (/usr and libalpm throw me off though). Consider adding an example use case to make it clear what this would be used for.
@firefish5000 I'm truly trying to use these hooks for customized patching without editing PKGBUILD
on every yaourt -Syu --aur
. And I'm not sure which directory(ies) must containing these hooks(scripts).
My current usage(google-chrome.hook):
#!/bin/bash
case "$1" in
"pre-install")
sudo mv /usr/bin/google-chrome-stable /tmp/google-chrome-stable.tmp
sudo mv /usr/bin/_raw_google-chrome-stable /usr/bin/google-chrome-stable
;;
"post-install")
sudo mv /usr/bin/google-chrome-stable /usr/bin/_raw_google-chrome-stable
sudo mv /tmp/google-chrome-stable.tmp /usr/bin/google-chrome-stable
;;
esac
If these are patch scripts, then I believe they would better fit in the users $HOME directory. Consider
aur_hooks_dir="$HOME/.yaourt/hooks"
(or perhaps package-hooks, to distinguish it from non-package specific hooks that pacman uses).
Chances seem high that the only one who will use the package-hooks on a system is the user creating them. But if you think otherwise, an additional aur_hook_dir in /etc could be used.
It's pretty trivial to maintain a local clone of an AUR package and periodically git pull --rebase
it with custom modifications on top, which is what I personally do in such a case. But there is already a feature to use customizepkg to modify the PKGBUILD automatically before building. There are several different versions of customizepkg available with different approaches to modification, surely one of these will suit you.
Hooks that can be run before/after installing a package might as well be pacman hooks in order to save on the confusion you're about to induce.
It allows to run some scripts before/after building/installing some package. I think it's useful sometimes.