Вообще говоря, для stable в этом мало смысла — обновления минорные.
Правда, жизнь немного сложнее сухой теории. Достаточно вспомнить сюрприз со сменой ядрёным апстримом API в 4.4.186+, приехавшее 4.4.172 и сломавшее сборку проприетарных драйверов... Но на такой случай прежний набор пакетов с ядром/модулями достаточно иметь в загашнике (или перед обновлением сохранить по removepkg --copy), либо воспользоваться неправильным (хронологическим, без удаления пакетов) зеркалом, например, этим: http://ftp.pieskovisko.sk/slackware/
Условно говоря, у тебя slackpkg upgrade / upgradepkg находит разницу в файлах между старым и новым пакетом и удаляет файлы которых нету в новом, потом распаковывает новый пакет поверх оставшихся старых файлов. Ну и всякие install/doinst.sh выполнит
installpkg просто распакует пакет поверх имеющихся файлов от старого пакета и выполнит install/doinst.sh.
Ядро, его модули и сырцы устанавливаются в виде /boot/vmlinuz-$VERSION-smp и т.д., /usr/src/linux-$VERSION а потом doinst.sh делает линки типа /boot/vmlinuz, /usr/src/linux на эти файлы/директории и запускает lilo/grub.
Поэтому, если нужно оставить старые версии нужно заблэклистить kernel-* и устанавливать новые версии kernel-* при помощи installpkg. Старые версии останутся нетронутыми, а стандартные линки будут указывать на свежеустановленные.
со slakfinder'a взять и через installpkg его поставить, добавив «старое» ядро в блэклист?
Зачем старое, все сразу (по обобщенным именам, как выше показывали и как оно изначально есть в blacklist, только закоментированное). slackpkg то, что добавлено в blacklist, просто «не видит» — исключает из обработки.
Slackware-current предназначена для тестирования будущего выпуска теми, у кого есть достаточно компетенции для самостоятельного решения возникающих проблем, и сообщения об обнаруженных ошибках.
Для обычного использования в случае частого обновления подходит только если достаточно софта, имеющегося в дистрибутиве. Как только появляется потребность в каком-то количестве стороннего софта, нужно понимать и быть готовым к тому, что обновление, содержащее изменение версий .so (.so-version bump) сломает использующий эти библиотеки сторонний софт; потребуется или его пересборка или грязный хак (как правило срабатывающий в случае незначительных изменений) в виде создания симлинка .so.старая_версия -> .so.новая_версия. Первое правильно, но дорого; второе дёшево, но не надёжно...
Третий путь: поставить все необходимое и не обновляться достаточно долго, чтобы решать накопившееся потом «одним махом». Тоже так себе сценарий, но наиболее рабочий из возможных.
Но, если уверены в себе, запретить вам пляски на граблях никто не сможет. Я предупредил :-)