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

Re: dpkg hooks (was Re: Upgrade report from "bo" to "hamm")

>>"Adam" == Adam P Harris <apharris@burrito.onshore.com> writes:

	I was responding, in part to the following statement
 Perhaps DPKG:TNG wil include some way of registering a script to run at
> the end of the configuration?  Any interactive but non-vital
> configurations could then happen at the very end, easing one point.  It
> would probably allow one running of inittex and one selection of ispell
> dictionaries.

 Adam> This would be a welcome addition to the system.  We'd just need to
 Adam> find a way to have dpkg trip off these scripts at the end of a run.
 Adam> We can't rely on apt to do this, since people will still be using
 Adam> dpkg, dftp, or dselect for a long time now.

 Adam> Rob Browning <rlb@cs.utexas.edu> writes:
 >> Manoj Srivastava <srivasta@datasync.com> writes:
 >> > 	Actually, I would like to see a hooks mechanism for the
 >> >  package management system desgned and implemented. This can take the
 >> >  place of the pre and post inst rm scripts; the currrent behaviour
 >> >  just being the default hooks implemented by dpkg.
 >> > 
 >> > 	Thus, bbdbv could just put a reconfig request in the
 >> >  after-package-configured-hook for VM, and that would e that.
 >> > 
 >> > 	The shaould also be a post-install-run-hook, and all menu call
 >> >  and emacsen-configure calls could be added to that hook, to be
 >> >  run when the installation is over.
 >> > 
 >> > 	This si a relatively simple, but very powerful technique.
 >> Consider this proposal seconded :>

	Now, the other part was: 

 Adam> I've considered this quite a bit. It would be nice to have a set of
 Adam> well-known, lengthy, oft-repeated installation step (inittex,
 Adam> update-menus, and I guess the dictionary stuff comes to mind).
 Adam> Package maintainer scripts could indicate they want these processes
 Adam> run.

 Adam> I think I would probably agree too but I don't understand what you're
 Adam> proposing.  My goal was to basically de-duplicate multiple, time
 Adam> consuming runs to things that lots of packages do, like update-menus.
 Adam> Manoj, does your scheme address this?

	Now, the hooks part was about being able to run scripts as
 needed. As to non-duplication, all the acripts need to do is make
 sure, at the end, only one copy is running. There as many ways of
 doing this. Solutions may involve lock files, time stamps, etc, but
 this is not an intractable problem. 

	Maybe one could design a basic algorithm that ensures that if
 multiple copies of the same script are registered, only one copy
 shall be run? Like touch a request file while registering the hook;
 the scripts then create a lock file; do the job, and create a done
 file. When a script acquires a lock, if a done file exists, and is
 newer than the request file, do nothing. 

	So, the lock serializes the scripts; the test for request and
 done files ensures only one script is run.

	Since the hooks are handled by dpkg; and dpkg is serialized,
 no race conditions are created. (it could be done without that, but
 then one would need another condition variable, and error recovery
 (decrementing the mutex guarded cond variable) is messy (especially
 for scripts).

 Though one were to tend the sacrificial fire for a hundred years in
 the forest, if another were to pay homage to a single inwardly
 perfected man for just a moment, that homage is better than the
 hundred years of sacrifice. 107
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E

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

Reply to: