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

Re: Hooks mechanism



Hi,
>>"Ian" == Ian Jackson <ian@chiark.greenend.org.uk> writes:

 Ian> I propose to have _one_ hook script for each package triggered
 Ian> by the hooks mechanism, which will be invoked for all hooks.
 Ian> This will make it obvious that it has to be idempotent.
	
	Ok.

 Ian> It will be much simpler if we don't have to record why the
 Ian> script is being run (ie, what triggered the hook) - then we can
 Ian> have the package have a new Status value meaning `need to run
 Ian> the hooks for this package'.

	Hmm. This last bit maybe problematic. See below. 

 Ian> * Package hooks.  The control file contains:
 Ian>      Hook-Packages: <dependency syntax>
 Ian> If any status change happens to any package listed or a provider of
 Ian> such a package, then the package whose control file this appears in
 Ian> has its hook triggered.  `Status change' includes such a package being
 Ian> installed, removed, or upgraded, unless all the versions of the
 Ian> package(s) involved fail to satisfy the dependency.

	Let us take an example. IF package A is installed, package B
 needs to provide a hook for package A. The package may break if the
 hook is present and pkg A is not; and if the hook is not present but
 pkg A is.

	If the hook script is just called, with no indication what
 happened; then the hook scripts needs have an easy way to determine
 the state of package A. At the moment, there is no easy (supported)
 method.

	You are already thinking pf providing the "pathnames of the
 new or changed file(s)" to the <checking-program> in the
 File-in-directory hook scripts; this should be an easy extention. (Of
 course, you may generate the new/changed file list on the fly for the
 script, but that is getting kludgy).

 Ian> * File/directory hooks.  The control archive contains a file
 Ian> `filehooks' with a list of absolute pathnames.  If dpkg installs,
 Ian> upgrades or removes a package which contains a file or directory whose
 Ian> name is listed in this file then the package with the filehook script
 Ian> has its hook triggered.

	Is there any limit to the number of hooks that a package may
 register? If not, then providing the name of the altered file/dir
 could help the hook script a bit (I do not feel strongly about this).

 Ian> * File-in-directory hooks.  The `filehooks' file contains a line of
 Ian> the form: <directory-path> \t<checking-program>
 Ian> In this case, after new or changed file(s) have been installed in the
 Ian> directory (or one of its subdirectories), the <checking-program> will
 Ian> be run with the pathnames of the new or changed file(s) _before_ dpkg
 Ian> leaves the installation/upgrade stage.  If the <checking-program>
 Ian> fails then dpkg's error message will say which package declared the
 Ian> check, but then back out of the install or upgrade of the package with
 Ian> the new or changed (hopefully faulty) file.  This is in addition to
 Ian> the usual function of the filehooks file.


	manoj
-- 
 "Based on what you know about him in history books, what do you think
 Abraham Lincoln would be doing if he were alive today? Writing his
 memoirs of the Civil War. Advising the President. Desperately clawing
 at the inside of his coffin." David Letterman
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


Reply to: