[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal: make kernel install easier



On Wed, 2003-08-20 at 14:46, Manoj Srivastava wrote:
    On 20 Aug 2003 10:51:54 -0400, Adam C Powell IV <hazelsct@debian.org> 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.

    	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.

    > So why not (optionally) automate the process a bit?  Use a directory
    > e.g. /usr/lib/bootloaders/ to put scripts for managing the .conf
    > files and running the bootloaders.
    
    > For example, quik could have debconf questions: "Manage quik.conf
    > using debconf?" and "Install new kernels automatically?" and perhaps
    > "Global kernel option defaults" (though perhaps this would be better
    > outside of each individual bootloader).  Then each kernel package
    > would have a low- to med-priority debconf question asking with what
    > options to boot the kernel starting from global defaults.  It could
    > also ask whether to make this image top priority in the .conf, and
    > what name string to use for this image.  Also, quik could Provide
    > virtual package bootloader which kernel-image packages could
    > Suggest.
    
    	Bloat. You have not yet demonstrated a need that can't be met
     with the current infrastructure (your examples are fraught with an
     ignorance of current practice).

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).

    > If there's interest (and no show-stoppers anyone can think of), I'll
    
    	Well, too late. There are show stoppers galore (lack of need
     for such bloat being just one of them).
    
    > start writing patches to kernel-package, lilo, maybe even quik :-) --
    > that is, unless someone else wants to, e.g. their maintainers.
    
    	Secondly, most of this creeping featurism does not belong in
     kernel-package proper, but should be off loaded to the hook scripts.

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).

    > [Please CC me in replies as I'm not subscribed.  And apologies if
    
    	In the old days, it was considered rude to ask questions on a
     forum when you were not subscribed.

Then I am glad I do not live "in the old days".

    > this has been brought up before; searches on lists.debian.org didn't turn up
    > anything.]
    
    	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.

Thank you for the kind and courteous reply,
-- 
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg



Reply to: