On Jul 10, Jakob Bohm <[EMAIL PROTECTED]> wrote: > Upgrading the kernel is a non-option for solving this. It is technically It's the best option we have so far, but you choose to ignore it.
> Like it or not, udev in etch MUST be a valid, functional, drop-in, no-reboot > upgrade from udev in sarge when running on top of any kernel image actually > included in sarge. Ditto for the vast majority of correctly custom-compiled > kernels based on the kernel-source and kernel patch files actually included > in sarge. Like it or not, this does not appear to be practical. > Does kernel 2.6.12 work with any udev version that also supports 2.6.8? As I explained, it's supposed to work without major breakage with the sarge udev package. > The best workaround would be to patch udev to make a single udev version > work with both kernel versions (2.6.8 and the etch 2.6.x, currently 2.6.12). I eagerly wait for your patches. > If this is too difficult, then packaging two versions of udev (one for each > kernel version) with trivial wrapper scripts is a tried and true solution, This would not work well for udev because the newer versions have a different configuration syntax (it's not reasonable to ask users and maintainers to support both) and provide more features to other system components which cannot be supported by the old versions. > This is not a new idea, it is a routine solution and a lot of cut/paste from Indeed, it's not new and I even knew about all this before you attempted to explain it to me. The difference is that I also know why it's not applicable. > [2] Specifically, that a system upgrade from one stable release to the next, > or from stable to testing/frozen can be done as dselect/apt-get/aptitude > dist-upgrade with no or few special precautions, and the corresponding > reboot delayed until the user is ready etc. This can be seen e.g. in the This has historically not been true for many !x86 architectures, BTW. -- ciao, Marco
signature.asc
Description: Digital signature
