Re: packages with hook interfaces and no documented hook policy
Neil Williams <codehelp@debian.org> writes:
> 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.
Ah, I see that I was a bit unclear. What I meant to ask, was just that:
Should a package providing hook infrastructure also define a policy for
its usage?
>> 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.
Yes, I see that point. Which implies that if you provide some hook
infrastructure without restricting its policy, then you are really
opening for *anyone* to break your package.
Kind of dangerous...
>> 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.
Huh? I use unattended-upgrades on my laptop as a way to keep it updated
without having to create the cron job myself. But I don't expect it to
force itself to run at times where I want to the laptop to sleep.
> One alternative would be to conflict with pm-utils.
Sorry, I still don't see what's so special about the unattended-upgrades
cron job. Couldn't e.g. logrotate just as well argue that it should be
allowed to finish its work before the machin is hibernated? Or any
program for that matter? hibernate is supposed to freeze running
processes, not wait for them to finish.
>> 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.
OK, sounds kind of reasonable. Except that I think I have to remove
pm-utils then.... I just cannot accept that the hibernate/resume process
becomes as bloated as a full shutdown/reboot.
> 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.
OK, I understand that I have opened a couple of bugs which will have to
be downgraded a bit.
Thanks for taking the time to answer this.
Bjørn
Reply to: