Arch Linux

Keep it simple: reboot right after updating the kernel. If you cant reboot right now just don't update.

Pierre: i don't like this approach :)

There have been several scripts created and posted on community-contrib that will keep /n/ kernel versions around, I would suggest you take a look at one of those.

with a new kernel, you just need to reboot there is no way around this. Deal with it ;)

jelly it's not true. just don't delete my precious modules :-)

This looks silly: either you remove the old kernel, either you don't. What's the point of having a package manager if you don't want it to manage your packages? If your feature request is to have parallel installable kernel versions (which is perfectly legitimate), then file the proper feature request.

> What's the point of having a package manager if you don't want it to manage your packages?

I want it to manage packages in smart way

> If your feature request is to have parallel installable kernel versions (which is perfectly legitimate)

Why should i need such thing? I just want to be able to use my system in it's full power even between kernel upgrade and reboot. Sometimes i just can't reboot, but i accidentally upgrade kernel with other packages without proper modules loaded and then i can't use those modules till the reboot (i don't want to add kernel to IgnorePkg). Modules are part of a kernel and so we should keep them while the old kernel is (booted) in memory.

It can screw with your head sometimes. eg.: i've been trying to mount remote NFS after kernel upgrade (without nfs module loaded) and mount said something like "device unavailable" or "access denied" (i can't remember). i was checking, fixing and restarting the remote server for 15 minutes till i've found that i just don't have module and it can't be loaded automaticaly by mount.nfs

So for you a "smart way" is to say something like "the changes will be applied at next reboot"? The only operating system I know of that does so is Windows, and making package operations even less atomic as they already are means less simplicity and more problems. Most pieces of software that try to be smarter than the user usually just fail.
Parallel installation of multiple kernel versions is a common way of dealing with the problem you describe (like they do at Debian's). You are really not expected to upgrade the kernel if you are not going to reboot the system.

moving modules to /dev/shm and creating symlink doesn't seem to be risky for me... worst thing that can happen is that modules will not be available which is current state, so there's nothing that can go worse than it's now.

So that when I downgrade my kernel my modules get installed in /dev/shm instead of the normal place ?

Rémy: can be handled in pre_install() using test(1)

I don't understand what you mean. What do you want to test for? Consider this scenario: I upgrade my kernel from version 2.6.38.3 to 2.6.39 and suddenly reaalize I'm gonna break my system if I don't reboot. So I downgrade back to 2.6.38.3. What do you think should happen.

I remember at least one other request like this one in the past. It got closed as "wont implement" but i cant find it right now. Since this feature request has been open for 10 days already and no other person got interested in saying "me too", on the contrary all the people who bothered replying said they dont like it, and its just one user that wants it, i'd encourage him to modify the kernel PKGBUILD to compile his own kernels the way he wants them.
-1 from me as well.

Rémy: you can test if the directory with modules is symlink or not. if it's symlink you should remove it before downgrading.

for example:

pre_install() {
test -L /lib/modules/$pkgversion-ARCH && rm /lib/modules/$pkgversion-ARCH
}

pre_remove() {
mkdir -p /dev/shm/lib/modules/
cp -rf /lib/modules/$pkgversion-ARCH /dev/shm/lib/modules/
}

post_remove() {
ln -s /dev/shm/lib/modules/$pkgversion-ARCH /lib/modules/
}

or we can implement some (eg.) /tmp/delete_on_boot directory which will get deleted by init each time to fix cases where /dev/shm is not ramdisk

I can't see why you wouldn't want to reboot, if you don't want to let your modules removed just add ignorepkg=kernel26. I would like to know the opinion of tpowa about this =)

-1 from me too, sorry. i understand your motivation but i like KISS better

I guess this is a general problem:

If you upgrade a program that is running, and it is not able to re-execute itself, weird things might happen. The kernel is one such program, but I'm sure there are others (I seem to remember that upgrading KDE causes "everything" to crash). I think the only sensible solution is to not do an upgrade if you are not prepared to reboot.

(Stuff like udev and dbus might be able to elegantly reexecute themselves, so a reboot is not necessary, but others will not.)