[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg triggers



On Sun, 31 Mar 2002, Anthony Towns wrote:

> On Sun, Mar 31, 2002 at 12:40:10PM +0100, Russell Coker wrote:
> > On Sun, 31 Mar 2002 12:36, Colin Watson wrote:
> > > On Fri, Mar 29, 2002 at 04:04:10PM +1000, Anthony Towns wrote:
> > > > Other applications are for "update-menus" and for things like "texhash",
> > > > which really only need to be run once after a complete apt-get
> > > > dist-upgrade (or maybe not at all if none of the applicable packages
> > > > got upgraded).
> > > It might make sense for mandb, too.
> > This sounds different to what I want.  I want a script to be run after every
> > package is installed.  But running a script after the completion of apt-get
> > would be handy too.
>
> A way of doing both would be to add a simple database, which maps an
> "event" to a script to be run. Possible events could be "dpkg run",
> or "postinst of <package name glob>". It'd seem like a more flexible
> infrastructure than having 8 directories to run-parts over for every
> package that's changed, at least. (iirc, run-parts is also pretty horrible
> at passing information to and from the scripts)

Implemented as a text file.

--
command event path-to-execute arg1 arg2 arg3
..
--

command == dpkg, dpkg-deb, etc
event = {before,after}{pre,post}{inst,rm}
path-to-execute = /usr/local/bin/my-event-hook
arg1 .. argN = %{pkg,%ver,...}

This syntax could also me extended to pattern match files upon extract.  And
could also be used to support 'exclusions' when extracting(ie, not extracting
doc/ files).

What I would like to see is a generic event running interface, with different
error returns deciding whether the event should be processed, skipped, or
conditionally ignored.

Anyone want to do this?  Oh, and not for dpkg 1.10(which is cvs HEAD).



-- 
To UNSUBSCRIBE, email to debian-dpkg-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: