On 20 Aug 2003 16:04:50 -0400, Adam C Powell IV <[EMAIL PROTECTED]> said:
> On Wed, 2003-08-20 at 14:46, Manoj Srivastava wrote:
> On 20 Aug 2003 10:51:54 -0400, Adam C Powell IV
> <[EMAIL PROTECTED]> said:
>> Greetings, Installing a new kernel package can be a bit of a pain,
>> especially for newbies, what with hand-editing lilo.conf or config
> Why on earth are you hand editing the lilo.conf file for every
> kernel image? The postinst already manages two symlinks for you
> that can be in the lilo.conf file.
> If you have to hand edit lilo.conf for every kernel image, you
> are doing something wrong.
> See my reply to Josh Lauricha: kernel-image packages corrupt the
> vmlinuz(.old) symlinks when removing a kernel, and switching between
> kernels with and without initrd.img is not supported.
You can replace the symlink handling of kernel-image packages
on the target machine, without modifying kerel-package. And yes, lilo
conf files can be tricky with the default symlink handling --- but
the example postinstall hook script demonstrates that all this canm
be handled exernally to kernel-image packages.
> For the clever, you can manage any number of symlinks
> automatically for yourselves; the latest kernel-package gives
> an example of creating a set of symlinks for 2.4 kerels,
> another set for 2.5 kernels, and so on.
>> files for other bootloaders, from grub
> Another bad example. For grub you do not need to muck around
> with symlinks at all, you have update-grub, and again, the
> kernel-package package gives examples on how to use this
> script.
> Then /usr/lib/bootloaders/grub would be very small and easy to
> write. My proposed mechanism would add finer-grained control of
> boot options (e.g. "apm=on" for 2.2 kernels but not 2.4) and of menu
> entry names/labels, with little additional coding.
The apm=on for 2.2 kernels can already be handled (see the
sample postinst hook script provided for hints). I suppose
dynamically creating labels is desirable, but all this can be a light
weight /usr/sbin/update-lilo-conf script.
> Please forgive me, I had not known that a newer version of quik had
> just been uploaded which supports such features, and that's what I
> use to boot my one fully-unstable machine (i.e. not just a chroot).
quik does not follow symlinks?
> Now that there are hook scripts, this makes some sense. But if you
> think about it for a few seconds, the "bloat" and "creeping
> featurism" of the proposed bootloader scripts is no greater than
> that required for hook scripts -- in fact, that's what they are
> (inspired by e.g. update-cluster).
I have no idea what update-cluster is, so I doubt if they were
inspired by that (I am an emacs user, hooks are old hat to us). In
any case, kernel-package alreasy impolements hooks.
The fact that you came in talking about patching
kernel-package without even being aware of current capabilities is
disheartening -- and leads one to suggest you look at what
kernel-image postinst does before you create new solutions.
> It has not only been brought up, solutions have been found and
> have been implemented.
> Again forgive me, I had not known these solutions had been applied
> to aboot, quik, palo, etc.
So do some research about what the postinst does already. If
you want to create a third party set of scripts to handle updating
various boot loaders, fine. But your use cases for such a change were
ill chosen.
> Thank you for the kind and courteous reply,
Thank you for the courtesy of researching the problemset
before proposing solutions.
manoj
--
%DCL-MEM-BAD, bad memory VMS-F-PDGERS, pudding between the ears
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
