On Thu, Aug 06, 2009 at 08:35:49PM +0200, martin f krafft wrote: > also sprach dann frazier <da...@debian.org> [2009.08.06.1853 +0200]: > > Any reason this couldn't be fully implemented externally to linux-2.6? > > The parsing code should be static enough to live outside, I would > > think. > > No reason why it couldn't happen externally. It just seems that the > linux-image packages are the logical place for it.
To me, it seems more like an external service. Like you mention, multiple linux-image packages could be installed at one time, so it would seem like the logic is something we'd want to factor out into a single standalone package. It is also very difficult to do any amount of rapid development within the linux-2.6 source package as new uploads require a lot of resources. > Otoh, if you have multiple images installed, only the one with the > highest version should be considered. True - though, theoretically this could be more complex than that. For example, just because 2.6.30 is installed doesn't mean that 2.6.26 isn't still configured to be the default. We could play ignorant and always tell the user that they need to reboot after installing any new kernel, but it would be cool if we could be more intelligent about it. It might make sense to do this as a commandline toolset, and let other people build tools on top as they wish. e.g.: $ kernstatus --booted-kernel UNAME=2.6.26-2-686 PKGVER=2.6.26-18 $ kernstatus --default-kernel UNAME=2.6.30-1-686 PKGVER=2.6.30-5 I could see using such a tool inside of s2disk to make sure that we will be booting the same kernel we used to hibernate. Possibly offtopic, I've also personally always wanted a simple, bootloader/arch independent tool that knows how to list the available kernels, and have the option to set a given kernel as the default for the next boot. e.g.: $ kerntool --list-images 2.6.30-1-686 2.6.26-2-686 $ kerntool --set-default 2.6.30-1-686 > A better approach would be something like > /var/lib/debian/reboot-required.d, where packages can drop files > containing reasons why a reboot is needed. 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. 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. -- dann frazier -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
