Update Sept 04, 2011⌗

As this still gets comments occasionally, I should clearly note that this is (and has been for some time) an accepted issue on Arch’s bug tracker. There is a basic accepted game plan for how it will be implemented, but is currently marked as low-priority. If you’re interested in the details look at: https://bugs.archlinux.org/task/16702#comment80122. Also, please do not comment on that bug report because it’s very close to being closed just to keep people from further commenting “new ‘solutions’ that we simply won’t implement."

Now, Arch Linux and I have had our differences in the past. It’s handling of documentation for instance has always been a bit backwards IMO. What’s that? I really have to recompile every single program which I want the API documentation for? Can we get with the times already and make perhaps -doc packages by default? Worried about their being lots of -doc packages when you do something like pacman -Ss some-program? Then put them in a separate repo call documentation and have it disable by default! This isn’t a hard concept people.

But that’s not what I want to complain about today. What really annoys me about Arch Linux more than anything else is it’s brain deadly stupid handling of kernel upgrades. Let’s go through a typically kernel upgrade: 1) A new kernel version is out that Arch wants to upgrade to, GREAT! 2) pacman -S kernel26 3) Delete kernel, initrd, and modules for the currently installed kernel 4) Install the new kernel, modules, and initrd.

Ok, there should be an obvious problem here. #3 deletes the current (typically working) kernel and replaces it. Well what if the new kernel has a serious regression in it on your hardware, or worse yet, what if it doesn’t boot at all? You’re now stuck. You’ll may well have to pull out a livecd, and try compiling the old kernel version again to get back to a working system. There are lots of things that could be done to fix the issue, but the fact of the matter is, why delete a working kernel with one that may or may not work?

So, there’s a problem. What should the solution be? Well, how I would do it would be something like this: Every kernel version PKGBUILD will have a version number in the pkgname. So instead of it being just kernel26, it’ll now be kernel-2.6.31 for instance. kernel26 will now be basically a dummy package that only depends on kernel-2.6.30. All of a sudden, whenever there’s a new kernel version that the Arch package maintainers want to upgrade to, they’ll change the kernel-2.6.30 PKGBUILD’s name, and update kernel26’s dependency to the new kernel version.

In other words:

pre-upgrade: kernel26 depends on kernel-2.6.30

post upgrade: kernel26 depends on kernel-2.6.31 no packages depend on kernel-2.6.30

Now, the only real issue with this system would be, what do we call vmlinuz26, System.map26, & kernel26.img be called and how should be updated? The first part could very simply just be versioned. kernel-2.6.30.img, vmlinuz-2.6.30, etc. This really shoudn’t be that hard, and I think would work quite well. Well, that could be a bit tricky, but really, it shouldn’t be that difficult in all honesty. We’ll take grub for instance. It’s very easy to just add new rules to grub and everything “just works.” So really, Arch could do like other distributions do (Debian I know does this, but IIRC others do too) and update grub automatically. For users that don’t like this option, it could be turned off in rc.conf.

Another option would be to still use version prefixed names for vmlinuz, but then have links that are just updated upon update (so vmlinuz26->vmlinuz-2.6.30 becomes vmlinuz26->vmlinuz-2.6.31) All of a sudden, things work pretty much how they are now, but you can still edit grub (either at boot time if the new kernel fails, or after the fact) to have your old kernel in there.

Now, with this in mind, the first option my be more appealing to the more liberal Arch crowd, but for the more die-hard (the one’s that chant KISS anytime you suggest a new feature for Arch) might not be as violently opposed to the second option. I also think most of the people in between wouldn’t really care too much either way, but I have a feeling more would probably favor the second option.

—Edit— I decided to file the feature request on Arch’s FS: http://bugs.archlinux.org/task/16702 You can comment there if you directly want to let the developers know how you feel, or here if you’re just wanting to tell me the idea sucks or if you like it, if you too have had problems with it, etc. In other words, I’d suggest commenting on the feature request if you have constructive input on how it may be implemented or why it shouldn’t, and here for anything else.