On Sat, Sep 12, 2009 at 11:34:20PM +0200, Marc - A. Dahlhaus wrote:
Well, so far i got much headwind against the trigger idea...
Just my 2 cents after reading this thread: 1) pacman -Syu = 20 updates that install info pages: This means running infodir 20 separate times (file-based) or once at the end of the transaction. 2) pacman -Syu causing update of kernel and modules. mkinitcpio runs for both packages (file-based) instead of once at the end of the transaction. If the hook script had a variable to hold the user preference of immediate or delayed, then pacman could keep track of those delayed triggers and run them at the end of the transaction. Of course this would only make sense for the hooks that can be delayed and pacman would default to immediate in the absence of such a variable. At this point, I've forgotten who was in favor of what on some of the finer details, so I'll just throw my opinions into the fray since it seems you are calling for such opinions: I share the concern over code duplication, but I do not agree that it should be taken out of the hands of the packager except where it can be reasonably hardcoded into pacman itself. If the user wants control, the hook script itself can give them that. Either way pacman has to know what trigger to run and when to run it, so it seems the PKGBUILD is a natural place to have an array of predefined hook names (like info). For those hooks that are unique to a given package, the PKGBUILD can tell pacman to register the hook (i.e. install the hook) prior to any other file being installed (to allow for preinstall hooks). Example of some possibilities: pkgname=example pkgver=1.0 hooks="("postinstall:gtkcache" "preinstall:uniquescript") <..> The really common ones, like info/man cache updates could even be hardwired into pacman to check for the installation/removal of such to trigger the corresponding action without having to put them in the PKGBUILD, though I don't consider a hundred PKGBUILDs all having postinstall:info in them as code duplication anymore than those same PKGBUILDs all having make && make install in them. If the cost is low enough, the same hardcoding could be done for any hook that runs on more than a few packages installed as part of core or extra. This isn't to say that pacman hardcodes the action itself, but rather hardcodes the trigger it is looking up in /etc/hooks, where scripts reside to do the actual work. ISTM, to ease the burden, pacman should be able to reverse an operation upon uninstallation without needing specific instruction. For instance: postinstall:gtkcache should naturally also mean postremove:gtkcache without having to explicitly state that in the PKGBUILD (however, explicitly stating it can be used to override in the corner case of something having to be pre instead of post or vice versa). I am also a fan of the hook script itself being the config file. A global hooks.conf would be a maintenance chore and parsing two files, one for options and one for the script seems needlessly expensive to both pacman and the user who is trying to manage his hooks. As for a hooks package for general hooks, I think that is a good idea so as to keep pacman OS-independent and avoid the problems that resulted in the mirror list being separated. Sorry this email became so long-winded. -- Jeff My other computer is an abacus.