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.
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.
> to yaboot/quik, aboot, palo,
> you name it. Yes, the kernel-image postinst runs lilo, but
> lilo.conf is invariably out of date, so this is relatively useless
> except for upgrades.
Rubbish. It is not our of date at all, as long as you have
written it corectly, and to be compatible with the image postinst.
> 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).
> 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.
> [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.
> 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.
manoj
--
We were so poor we couldn't afford a watchdog. If we heard a noise at
night, we'd bark ourselves. Crazy Jimmy
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
