On Sat, Jul 17, 2010 at 12:23:48PM -0300, Rafael Beraldo wrote: > 2010/7/17 Thomas Dziedzic <gostrc@xxxxxxxxx> > > > On Sat, Jul 17, 2010 at 10:10 AM, Ng Oon-Ee <ngoonee@xxxxxxxxx> 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! > > > > > > 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. > > > > > > > > > > Agreed with Ng Oon-Ee on this one. > > > > > In this case, I think the best would be the middle ground. I mean, when > upgrading the kernel, the older would be named “vmlinuz26-old” and the > initramfs “kernel26-old.img”. This would be a secutiry measure --- what if a > new kernel doesn't work? > Then you're boned anyways because /lib/modules/$(uname -r)/ was replaced. It'll be missing in the case of a 2.6.X upgrade. d
