On Mon, 17 Jan 2011 18:43:23 +0100 Bjørn Mork <bjorn@mork.no> wrote: > Can any package just provide the hook directories it want without an > explicit policy? A general policy for all hooks sounds like a difficult thing to create - it could easily be so nebulous as to be unusable. Probably better for each package supporting hooks to handle their own. If the hook syntax is correct for the package running the hook, that would be the majority of such a policy being met. Hook policy is in the hands of whichever package is trying to run the hooks. If the hook meets the requirement of that package, it's not a bug to provide such a hook. > And can any package provide hooks in such > directories, even if there is no policy for its usage? Does it make > any difference if the hooks are configuration files? Arguably easier if they are configuration files so that the admin can optimise which hooks are used. Even so, there are situations where such hooks should *use* existing configuration files rather than necessarily being configuration files themselves. > My claim is that packages like unattended-upgrades and pm-utils are > completely unrelated to each other, I'd disagree - if one package provides a hook for another package, those packages are clearly related. One is executing a known API of the other - that's a definite relationship. > and that a hook in > unattended-upgrades which breaks pm-utils by preventing hibernation > is a critical bug, even if the breakage seems intentional. Sounds to me as if unattended-upgrades would have a perfectly good reason to prevent hibernation, if configured in that manner. I'm not sure it's a bug at all. Would be better if unattended-upgrades made this step configurable, true. Why use unattended-upgrades if the machine is not on a UPS? That would seem to be the typical use case to me (the UPS providing a period of time normally sufficient for an unattended upgrade to complete whilst on UPS power before shutting down). Other setups would need different configuration and maybe unattended-upgrades ought to support that. However, that would be a minor or wishlist bug. One alternative would be to conflict with pm-utils. > But i may be wrong. Maybe it's OK to break any package with a hook > interface and no policy for its usage, as the package itself then has > provided the necessary infrastructure for breaking it? The package providing the hook interface makes itself accessible to other packages which may provide hooks. As long as the hook syntax is correct, it is up to the package providing the hook to ensure that only relevant functionality is exposed via the hooks. If a package contains a hook for that program which uses valid syntax to make a particular change, it's not a bug if that functionality is changed in that manner by that hook. There may be a bug in the package supporting hooks if the changed functionality has adverse effects - that particular functionality may need to be inaccessible from hooks. There may be a bug in the package containing the hook if the hook breaks the package processing the hook but that bug is clearly a bug affecting two strongly related packages. This package may need to allow for such hooks to be disabled in the package configuration to fix such a bug. The hook should also take steps to ensure that it is only active in appropriate situations, in this case when an upgrade is actually in progress. Neither bugs would necessarily be RC - it all depends on whether there is data loss or some other reason for such severity. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgp_MuXq7OAgr.pgp
Description: PGP signature