On Mon, 17 Jan 2011 20:54:12 +0100 Bjørn Mork <bjorn@mork.no> wrote: > Neil Williams <codehelp@debian.org> writes: > > On Mon, 17 Jan 2011 18:43:23 +0100 > > Bjørn Mork <bjorn@mork.no> wrote: > > 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? It can, it doesn't have to. What matters is that the package only exposes appropriate functionality via hooks and makes appropriate settings configurable. > >> 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... No. The hooks cannot do everything - the package controlling the hooks needs to handle the hooks sensibly. > > 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. Use cron-apt instead? unattended-upgrades is more commonly used on servers with a PSU attached. I wouldn't ever use any form of automated upgrades on a laptop - no guarantee the laptop has a connection even if it is on. I'm afraid this comes down to error between chair and keyboard. Most people just wouldn't put those packages on a laptop. > 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. Different package objectives. cron-apt may be what you are actually thinking of. Even then, I wouldn't use cron-apt on a laptop. The hibernate hook could just be configurable, that's all. In most cases, it probably is the right hook and on most laptops, automated upgrades are simply not useful. > 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. No, that's just insane on a laptop, pm-utils is much more useful IMHO. Do you want a laptop that doesn't hibernate at all? Manage the updates yourself when you've got time or when you're doing something else. > > 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. You could also seek clarification of the package descriptions to make it clearer that unattended-upgrades is more commonly found on a server than a laptop. (Unless it's a laptop with a faulty battery and is largely used as a desktop anyway.) -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgp9aVGNJ03QP.pgp
Description: PGP signature