Re: dpkg hooks (was Re: Upgrade report from "bo" to "hamm")
Hi,
>>"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).
manoj
--
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: