On Thu, Aug 06, 2009 at 09:34:23PM +0200, martin f krafft wrote: > > Yeah, that might make sense - esp if there are other such > > packages, but I can't think of any myself (thankfully). But > > I think for the kernel case we would probably want that dropped-in > > file to be managed by a more intelligent tool rather than trying > > to figure things out (only) inside of maintainer scripts. > > Ha! When I teach sysadmining courses, my students get to reboot > their machines *all* *the* *time* (and they have to do exercises and > brainstorming in the mean time). The reason is simply that anything > could break, and if the next boot will fail, then I'd like to know > *now*, not then.
Yeah, rebooting is certainly a good sysadmin practice, esp after a significant upgrade, but I just can't think of many packages that need to request a reboot from the admin during install/upgrade. > > I do like the idea of a cronjob that checks periodically to see if > > the kernel-that-would-be-booted-next is the same kernel that is > > currently booted. It would be able to detect a mismatch introduced > > outside of a dpkg operation - for example, if the the user > > reconfigures which installed kernel is the default. > > This is a twist on my proposal. All I wanted is a tool that knocks > me over the head like "hey, you installed a new 2.6.30 last week and > were to tired or unable to drive to the colo centre, or you were too > much of a chicken to do a remote reboot. But you still have to do > it. And till then, I'll mail you every day!" It is a twist (well, an extension), but one I suspect users to want. If you are running a 2.6.30 and install an updated 2.6.26 (or vice-versa), do you want to be nagged everyday until you reboot? It would be preferable to only nag if the default-kernel was updated (either by installing 2.6.31 or an updated 2.6.30). -- dann frazier -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
