Re: Hooks mechanism
Hi Ian et al!
As I promised to read this again and give comments tonight, here
it goes.
First of all you should give a description how you expect the hook
mechanism to work.
What we need is a mechanism that tidies up and final-configures some
packages after all packages were unpackaed, installed and configured.
This would help with the following tasks:
. Re-generating the menu system
. Selecting a language for all the i<lang> and w<lang> package
. Updating mime packages
. Running initex
. Select the main X-server
. Select the main window manager
. (Edit alternatives)
Your design is more complicated, thus a description would be a good
idea so people know what the detailed design is all about.
Ian Jackson wrote:
> * Packages whose hook scripts fail should _not_ be marked as properly
> installed.
Exactly.
> * Hook scripts will often interact with data supplied by many other
> packages (e.g. the menu system). The package which `owns' a
> particular set of this data should be able to validate the data
> supplied by a package, so that a package with a bad hook data item
> (better name, please?) can be marked as broken.
Am I in the position of creating a new name? If so I'd vote for
"hookie". (pronounced hu:ki, u: like in mood).
This sounds good. It doesn't look like too much work if each hookie
either contains a package identifier or if the hook script calls dpkg
-S to detect the offending package.
> * Sometimes hook data will be supplied by conffiles. The admin will
> be required to run an `update' program if they edit the conffiles.
> If they get the syntax wrong then the update program may fail, and the
> package with the hook script will be marked as broken (?)
Which sounds corerrect to me. In that case the package *is* broken,
broken by user though. If it would be re-installed it still would be
broken if the user doesn't let dpkg overwrite the conffile.
> * Hook scripts should be triggerable from other events - at least, on
> status change of a certain named package (or provider thereof) and on
> installation/removal/modification of a certain file or directory.
I don't understand your background for this one. Hook scripts need to
be triggerable by the packages that supply hookies. However this
could be done in two ways:
a) Each package that supplies at least one hookie sets an
appropriate hook or
b) the package containing the hook script itself defines directories
and files to watch for modifications.
> * Hook scripts should not usually be a prerequisite for the event
> taking place; instead, all packages' hooks should be run later.
> Otherwise the error handling complexity (and possible recursion) will
> become even more fearsome.
The hook scripts should be run after all regular installation tasks
are finished. However it will become problematic if certain hook
scripts depend on data supplied by others and they need a certain
ordering.
Another thing that comes to my mind is "Configure-at-once" which is
partially by some libraries in order not to screw the system.
> * One package's hook(s) cannot invoke another's: ie, the hook scripts
> are run last, and cannot cause more hooks to need to be run.
This looks fine. However I wonder if we can disallow for hook
scripts to depend on data supplied by other hook scripts.
> I propose to have _one_ hook script for each package triggered by the
> hooks mechanism, which will be invoked for all hooks. This will make
> it obvious that it has to be idempotent. It will be much simpler if
> we don't have to record why the script is being run (ie, what
> triggered the hook) - then we can have the package have a new Status
> value meaning `need to run the hooks for this package'.
Could you translate this for non-native english speakers? I have big
difficulties understanding it, especially the first sentence.
I don't get your idea because I don't want to restrict packages to
only set one particular hook or install only hookies for one
particular hook resp. I also don't want to restrict certain packages
to only contain a maximum of one hook script. However the latter
would be easier to achieve.
> Possibly this script ought to be the postinst, but I don't think so,
> because a state change to `not-configured' ought to involve running
> the prerm and we don't want to do that.
I also don't understand this. The postinst has nothing to do with the
hook system - imho. Hookies should be installed as regular files and
packages triggering a hook will do this by simple installing the file
and letting dpkg notice this or by explicitely defining one or more
hooks whose script needs to run at the end of the installation.
> So, how about a new `posthook' script, kept in the control archive,
Why that? I would have expected that it would be installed in
/usr/sbin, so it may be called by the administrator as well.
> and new Status values `hook-triggered' and `hook-failed'.
> `hook-triggered' means that something on the system thinks the hook
> should be run, and `hook-failed' means that the posthook script
> returned a non-zero exit status.
>
> If A -depends-> B then dpkg will not run the posthook script from
> package A if B is not `installed' (this means that if both A's and B's
> hooks are triggered by an event then B's, if any, will be run first).
This looks somewhat logical.
> So, how do we invoke these hooks ? I propose three main mechanisms:
>
> * Package hooks. The control file contains:
> Hook-Packages: <dependency syntax>
> If any status change happens to any package listed or a provider of
> such a package, then the package whose control file this appears in
> has its hook triggered. `Status change' includes such a package being
> installed, removed, or upgraded, unless all the versions of the
> package(s) involved fail to satisfy the dependency.
I don't understand the idea behind this.
> * File/directory hooks. The control archive contains a file
> `filehooks' with a list of absolute pathnames. If dpkg installs,
> upgrades or removes a package which contains a file or directory whose
> name is listed in this file then the package with the filehook script
> has its hook triggered.
I don't understand either.
> * File-in-directory hooks. The `filehooks' file contains a line of
> the form:
> <directory-path>\t<checking-program>
> In this case, after new or changed file(s) have been installed in the
> directory (or one of its subdirectories), the <checking-program> will
> be run with the pathnames of the new or changed file(s) _before_ dpkg
> leaves the installation/upgrade stage. If the <checking-program>
> fails then dpkg's error message will say which package declared the
> check, but then back out of the install or upgrade of the package with
> the new or changed (hopefully faulty) file. This is in addition to
> the usual function of the filehooks file.
This does something else then I would have expected. Speaking of the
menu sytem this would mean that update-menus would have to be called
for each and every new menu file which is rediculous. I would have
expected that dpkg would carry a flag "to-run" or "not-to-run" for
each hook script and whenever a new or modified hookie is detected the
flag goes up.
> Good practice would be for all packages which use a particular hook
> directory to depend on the same core package containing the checking
> script.
Would the xfig package contain a hook on update-menus? If so this
doesn't make sense since no package that provides menu inforation
needs to depend on the menu package itself. It's an add-on.
> We need an escape syntax for the `filehooks' file in case people want
> \n's or \t's in their filenames. C's \ooo will do (but means we have
> to escape \ as well).
>
>
> What does it mean to trigger a package's hook ? If the package is not
> installed and configured (ie, state half-configured or worse), then
> nothing happens. From states `installed' and `hook-failed' the
> package gets put back into `hook-triggered'.
>
> dpkg will run hooks after each normal processing run, unless told
> otherwise.
dpkg should only run the triggered hooks at the end of a regular
installation/configuration run.
I realize that there are still some open issues wrt. hooks.
Joost Witteveen wrote:
> To be more clear, let me give an example.
> dpkg installs the Packages a, b, c, that all have
> `Package-Hooks: menu'.
> So after dpkg is ready, dpkg will run the menu posthook once. Suppose that
> package b and c have a corrupt menufile. Will update-menu then run
> something like `dpkg --corrupt-hook b c'? This may be tricky, as it was
> dpkg itself that exec-ed the menu-hook script.
I would expect the menu posthook would simply write the names of the
offending files / packages on stderr and dpkg would read them.
Regards,
Joey
--
If you come from outside of Finland, you live in wrong country.
-- motd of irc.funet.fi
Reply to: