Ciao Marco, I've been working on wrapping my head fully around the various issues with the udev and kernel upgrade, to ensure we have it documented properly in the release notes. It's clear to me that we will need to include documentation of this issue in the release notes no matter what changes are made to the packages, because users will need to know that the new udev won't work correctly with the Debian 2.6.26 kernels. At the same time, I think something needs to change in the packages to improve the 'dist-upgrade' experience, because we both know many users won't read the release notes. First, what happened to the idea of using 'Breaks'? This was proposed months ago, but it hasn't been implemented yet in the package. Should I provide a patch that implements this? Second, I've done some research and testing regarding the nature of the incompatibility with CONFIG_SYSFS_DEPRECATED. From what I see, the primary impact of dropping the compat code from udev is that udev rules will no longer be applied to certain devices, such as block devices and network devices. This will break /etc/udev/rules.d/70-persistent-net.rules, and break any permission-setting on disks (e.g., the 'disk' and 'floppy' groups) and certain alias symlinks for CD drives, but those are the only problems I've been able to identify on a standard as a result of running udev 160 with CONFIG_SYSFS_DEPRECATED; and of these, only 70-persistent-net.rules is potentially a boot-breaker, and would still permit booting the system far enough to rescue by hand at console (i.e., the same process one would use if a newer kernel was installed but not configured to boot by default, which is one of the scenarios that currently permits bypassing this preinst error). So do you know of any other things that will break, or can you provide pointers to other areas I should look at? You mention in the bug that some rules "will not work in ways beyond most people's ability to understand", but I don't even see any documentation here for those of us who *do* have the ability to understand and want to try to explain it to the others. :-) If there aren't any other issues, then IMHO the case is clear for downgrading the CONFIG_SYSFS_DEPRECATED handling from a preinst abort to a preinst debconf note (i.e.: interrupt the upgrade before udev unpack, to make sure the admin gets the message before we proceed). Right now, the cure (aborting the install of a core package during a dist-upgrade, leaving apt in a difficult-to-fix state) is definitely much worse than the disease (some devices not fully configured after reboot if the kernel isn't upgraded, requiring the user to grab a console shell to install a proper kernel). Third, you write that the old udev *also* won't work with the new kernel. Can you be more specific? In my testing, this also works fine; I wasn't able to identify anything out of place when rebooting to a 2.6.32 Debian kernel with a lenny udev. Finally, you comment in <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571255#89> that "the new kernel (indirectly) depends on a newer udev." In my testing, I'm able to install a 2.6.32-5 kernel package from squeeze directly onto lenny without upgrading udev in the process. When you say it "indirectly depends", do you mean that there is a *logical* dependency that isn't reflected in the package dependencies, or are you referring to some earlier situation whereby upgrading the kernel package did pull in a udev upgrade at the same time? To summarize, with the information I have available, I believe there are two changes that should be made to the udev package: - add the Breaks: linux-image-2.6-$flavor (<< $SYSFS_DEPRECATED_fixed_version) to udev, as discussed - change the preinst CONFIG_SYSFS_DEPRECATED abort to a debconf error note warning users about the network, permissions problems if they don't install a new kernel But I know that I may have overlooked some details. If you see any problems with my suggestion, please let me know what they are so that I can look for better solutions. And if there aren't problems with this proposal, I'm happy to prepare a patch to the package for this if that would be helpful to you. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature