On Wed, 20 Jul 2011 04:52:59 -0400 (EDT), Ben Hutchings wrote: > > Boot loaders *should not* maintain symbolic links, since that means > duplicating logic (and there are probably cases where multiple boot > loaders are installed and they may trip over each other).
I agree that if it's going to be done it would be best to do it in one place (i.e. avoid duplicating logic). > > Hook scripts will just perpetuate the use of the undocumented > /etc/kernel-img.conf. Hmm. I don't follow that logic. If symbolic links are maintained in hook scripts, then it makes sense to me that the user would set "do_symlinks = no" in /etc/kernel-img.conf to avoid duplication of effort. That's what I do. And if do_symlinks is set to no, then the settings for link_in_boot and relative_links become meaningless. And that's one more step in the direction of eliminating /etc/kernel-img.conf. To me, it's similar to setting "do_bootloader = no" in conjunction with providing boot loader hook scripts. Once boot loader hook scripts are provided, boot loader invocation logic can be eliminated from the kernel image package maintainer scripts, and the value of do_bootloader in /etc/kernel-img.conf can be ignored. Similarly, once symbolic links are maintained in hook scripts, the values of do_symlinks, link_in_boot, and relative_links in /etc/kernel-img.conf can also be ignored, and symbolic link maintenance logic can be eliminated from the kernel image package maintainer scripts. It's almost an exact analogy with boot loader hook scripts to my way of thinking. What I was thinking was that if the hook scripts detect pre-existing symbolic links they will maintain them, and if symbolic links don't currently exist, they won't create them. Here's what I'm currently using on my system. For /etc/kernel/postinst.d I have a hook script called zy-symlinks, available here: http://users.wowway.com/~zlinuxman/kernel/postinst.d/zy-symlinks and for /etc/kernel/postrm.d I have a similar (but not identical) hook script, also called zy-symlinks, available here: http://users.wowway.com/~zlinuxman/kernel/postrm.d/zy-symlinks That gives you some idea of what I had in mind. Note that since the name starts with "zy", they will be invoked before any boot loader hook script, which must start with "zz". Yet, they will be invoked after any currently-existing hook script other than a boot loader hook script. In particular, they will be invoked after initramfs-tools. That is the order in which it needs to run. > > I would like to see these 'traditional' boot loaders provide the option > to update their configuration automatically. This should be done with > the aid of the new 'linux-version' command from linux-base. I guess my working definition of "traditional" boot loaders means anything other than grub (either version). But keep in mind that on some architectures a "traditional" boot loader is all that is available. zipl is all there is for s390, for example. That's a nice idea, but there are implementation problems that come to mind. I don't know about zipl, I'll check; but I do know that lilo, for example, is limited to 15-character names in it's labels. The traditional labels, used with the symbolic links, are something like "Linux" and "LinuxOLD", which are well within the 15-character limit. But if one attempts to auto-generate labels based on the name of the kernel, I can easily see a problem with guaranteeing uniqueness while still remaining within the 15-character limit. Also, since each boot loader has its own unique configuration file format, similar logic will need to be invented multiple times. > > I have been meaning to work on this, but it's just one of a long > list of tasks. I didn't start this thread as criticism. As a matter of fact, I am amazed at the prolific productivity of the kernel team. I don't know how you find time to do all that you do. But I didn't want to wait until the last minute to bring up the subject. I want to give whoever needs to make changes plenty of time before the freeze to get things implemented. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1454887986.786413.1311161961069.javamail.r...@md01.wow.synacor.com