On Sat, 2010-07-17 at 10:42 -0500, Thomas Dziedzic wrote: > On Sat, Jul 17, 2010 at 10:38 AM, Victor Lowther > <victor.lowther@xxxxxxxxx> wrote: > > On Sat, 2010-07-17 at 23:10 +0800, Ng Oon-Ee wrote: > >> On Sat, 2010-07-17 at 09:17 -0500, Victor Lowther wrote: > >> > On Sat, 2010-07-17 at 18:05 +0400, Евгений Борисов wrote: > >> > > I think it's a bad idea, because the directory /lib/modules/$oldVersion$ > >> > > will be removed when the package is upgraded kernel. Trivial solution not > >> > > exists. > >> > > >> > My solution is to hand-roll my own kernels and initramfs'es after > >> > removing the kernel and mkinitcpio packages. The way Arch handles its > >> > kernel packages is a weak point -- Fedora and Ubuntu get this bit right. > >> > >> Yeah, why not keep all previous kernels and headers around. We could > >> automatically extend menu.lst too! > > > > It wold be better than updating to a new kernel, rebooting, and having > > to boot to a LiveCD to get back into your system because the new kernel > > fscked things up. > > > > Keeping versioned header files also comes in handy -- I take it you heve > > never tried any sort of testing with out-of-tree drivers or kernel > > subsystems? Using DKMS on arch is a pointless waste of time because > > older kernel headers are not kept around. > > > >> I'm not sure what you like about Fedora and Ubuntu handling of kernels, > >> but I found it very annoying to have all that stuff hanging around. > >> Would be worse with rolling release I'm sure. > > > > I like knowing that I will not have to hunt for a LiveCD or a rescue USB > > drive if a kernel update renders the system unbootable. > > > > > > This wouldn't be a problem if you have a backup kernel :) Oh, I do. I would just prefer to work with the package management framework, not work around it. -- Victor Lowther LPIC2 UCP RHCE
