On Oct 16, Greg Alexander <debg...@galexander.org> wrote: > udev 146-5 was installed as a result of dependencies while I was > upgrading my computer. I happened to be in the process of installing a > new kernel that had inotify support, but I was at the moment running a > kernel without inotify support. The udev preinstall script complained > that inotify was not supported and would not proceed, even with dpkg This is considered a feature, because otherwise the installation would stop in postinst and make installing a new kernel package impossible.
> --force-all. Due to the aborted upgrade and dependency mess, apt was in > an unusable state until I cleared this hurdle, so it needed to be > resolved prior to rebooting into the new kernel! Please clarify in detail exactly what prevented you from upgrading the kernel. It is also worth noting that you were using a self-compiled kernel, so you are on your own in keeping it up to date. > Older versions of udev would complain on startup about missing inotify > support, but would (mostly) function. This is the correct behavior, as This one does not and me and the upstream maintainer are not interested in revisiting this design decision. > But in the meantime, the hurdle in preinstall is a real nuissance. It > happens to skip the check if something like /etc/udev/kernel-upgrade is The purpose of this mechanism is to support upgrades of official Debian kernel packages, not of custom kernels. > * the preinstall script could notify the user of the possibility of > creating this /etc/udev/kernel-upgrade file, so they can override the > test without taking apart the control.tar.gz Maybe. I would rather not documented this, because it will encourage people who do not understand the consequences to break their systems. -- ciao, Marco
signature.asc
Description: Digital signature
