Re: Hooks mechanism
> * Packages whose hook scripts fail should _not_ be marked as properly
> installed.
Although for the menu package this will require some work, I think
the goal is good, and I'll try to implement it as soon as possible
after I get a dpkg version that supports this.
However, I have some uncertenty as to the hook script is going to inform
dpkg what package's hook script fails.
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 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'.
Thinking only of the menu package: I don't _want_ to know why the
menu posthook is being run. I think this is quite general, but...
> So, how about a new `posthook' script, kept in the control archive,
> 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.
I really like the posthook idea.
> * 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.
OK, so if package A has `Hook-Packages: menu (>>1.4)', then if
menu is not installed or the installed version is 1.4 or lower, dpkg will
not trigger the posthook of menu? This is cool...
How about `Hook-Packges: menu (>>1.4), menu (<<2.0)'?
If menu-1.3 is installed, does this:
a) cause menu's posthook to be triggered for the second part of that
dependancy, but not for the first?
b) cause menu's posthook not to be triggered as not all of menu's
dependancies can be satisfied, or
c) show that I'm just as sick as the example I'm giving?
Oh, may I add that in the menu case (and maybe more general) it is
not very usefull to be able to specify menu versions. Although most
menufiles really do need `menu (>>1.4)', just installing one package
that has an older menufile on a machine with menu-1.3 installed,
will case dpkg to run menu's posthook file, and that will in turn
read every file in /usr/lib/menu. But maybe other hook-users will
do things differently.
> * 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.
What do you mean with the `control archive'? Is that the ar archive in
the hook-providing package? So, again in the menu case, this would mean
that all I have to do is create one file with `/usr/lib/menu\tupdate-menu'
and nobody will thereafter have to mention `update-menus' in their
postinst scripts? Cool...
Thanks,
joostje@debian.org
Reply to: