On Sun, Jul 10, 2005 at 01:02:11AM +0200, Marco d'Itri wrote: > On Jul 10, Jakob Bohm <[EMAIL PROTECTED]> wrote: > > > It seams that if getting udev 0.6x quickly rewritten to support all > > udev-based kernels in one version is too much work or too controversial, you > > should do what modutils, cdrecord and other packages usually do for *major* > > kernel upgrades (like 2.4.x to 2.6.x): package two versions of the source, > > two sets of binaries (in one .deb) and some wrapper scripts or binaries to > > exec the right one depending on the kernel version. > No, this would be hell to maintain. So far it looks like that upgrading > the kernel before udev will work well enough to finish the upgrade.
Upgrading the kernel is a non-option for solving this. It is technically impossible [1] and even if it was possible, it would be a major removal of a primary feature of the Debian distribution and packaging system as a whole [2]. 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. Because sarge has already released, those kernel versions are now "cast in stone", as is the udev version actually shipped in sarge. Any point release updates to sarge only add to the list, they do not remove the need to correctly upgrade from Debian 3.1r0. Thus technically there is no way around the need to ship (and thus maintain) a 2.6.8 compatible udev package named udev in etch. Nor is there any way around ensuring that if whatever kernel ships in etch (like 2.6.16 at the current schedule) is still using udev, that switching back and forth [3] between those two kernel versions can be done without manually installing, removing, upgrading, downgrading, reconfiguring or otherwise manipulating the etch udev package or anything else on the non-volatile disks of the system. But just to clarify the situation: Does kernel 2.6.12 work with any udev version that also supports 2.6.8? If yes, that is the udev version that can go in etch (and thus sid). If no, then either we cannot upgrade to kernel 2.6.12 or some workaround needs to be coded. 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). 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, already used for the similar breakage of modutils between the 2.4.18 (from woody) and 2.6.8 (from sarge). And if you don't know how to package 2 udev versions in one package, then look at my sample code posted in this report, or the code in module-init-tools in sarge, or the code in cdrecord in sarge, or the similar code found in various other packages with kernel-dependent functionality, including glibc. > > (If you tried to discuss your ideas with maintainers before starting to > write down big designs you would probably save a lot of time.) > This is not a new idea, it is a routine solution and a lot of cut/paste from sarge. The only thing that took time was double checking various boring facts, spell checking my mail etc. -Jakob Footnotes: [1] Changing kernel versions can only happen at system reboot. Upgrading udev or any other package must happen before or after a reboot. So there will be a period of time during this process where only one of the two has been upgraded, and many parts of the system must be 100% functional during that period in order to successfully complete the upgrade. This includes any device needed to actually run the packaging system and its user interface, for any and all of the various media options available to our users for both .deb files, local disks and user interfaces. Including, amongst others, a huge portion of the udev managed devices and modules. And there is also the possibility that the second of the two upgrade steps may fail or need to be redone, e.g. due to network, disk or power failures. An even more demanding possibility is if the reboot attempt reveals a need to recompile the etch kernel with different options to match the users hardware etc. Then gcc and other toolchain stuff also needs to run on the half-upgraded system. [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 release notes for at least hamm, potato, woody and sarge, and possibly bo as well. [3] Since very early Debian release (I seem to recall this being in bo), all kernel image installs moves the previous kernel from linux to linux.old and all the boot loaders default to allowing the user to boot either at will. This mechanism exists specifically to recover from kernels that do not boot properly. Thus if a problem occurs, the user is expected to use this or other mechanisms to revert to the previous (2.6.8) kernel while diagnosing and fixing the problem. This may cause the installed udev files to see maybe 2.6.8, then 2.6.12, then 2.6.8, then 2.6.8 again, then a working 2.6.12 etc. in any order. Thus udev cannot assume that a boot with 2.6.12 will not be followed by a boot of 2.6.8, and thus cannot simply "delay" irreversibly updating some files until the first 2.6.12 boot. -- This message is hastily written, please ignore any unpleasant wordings, do not consider it a binding commitment, even if its phrasing may indicate so. Its contents may be deliberately or accidentally untrue. Trademarks and other things belong to their owners, if any. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
