On 05/07/15 03:11, Andrew Gregory wrote: > On 07/05/15 at 12:00am, Allan McRae wrote: >> Idea: Do we want to add a field that provides suggest text to display >> while it is running. I assume pacman will state what hooks it is >> running and something better than "Running foo.hook..." would be useful. > > As of now, hooks are treated similarly to scriptlets; no output is > shown unless the hook itself generates it. I was considering adding > some sort of message, but hadn't decided on it yet. If we add one, > I agree allowing hooks to specify a name/description would be useful.
I definitely think we should have one. Some of the standard things hooks will do take time, and from a pacman poin of view I would like a display message instead of looking like it is hanging. >>> Unlike pacman.conf multiple values are *not* allowed on a single line. >> >> Is there a reason for this? Are they allowed for Target? > > For simplicity and because the values can technically contain > whitespace. Target does not allow multiple values on a single line. > OK. <snip> > My tentative plan for providing hooks with the triggering files in the > future is to allow hooks to specify that file lists should be provided > to them on stdin. Having them explicitly request the file list would > make it easy for us to avoid a significant amount of unnecessary > overhead if they don't need it. Providing it to them on stdin would > avoid the problem of potentially exceeding the maximum command line > length and prevent the need for complicated substitutions in the Exec > command. > > If that plan is agreeable to everybody, it can be implemented later > without disrupting any of the existing implementation so I would like > to go ahead and get an initial hook implementation merged before > worrying about file lists. That is fine to me. As far as I am concerned, handling info file database updates is the primary target. That should be readly done by passing the file list on stdin. Allan
