"I decided to just bite the bullet, and call the next version 3.0. ItWhen 3.0-rc1 was released the Kernel Team had to decide what version to use for it in Ubuntu. We typically upload every -rcN release within a couple of days of its release so the pressure was on. We could simply call it 3.0.0 knowing that all the current scripting would cope, or as 3.0 better matching its official name knowing this would not be plain sailing. This was not a decision we could delay as in Debian versioning 3.0 < 3.0.0 so we were likely to be committed for Oneiric if we uploaded using 3.0.0. It is also not clear from upstream discussion what version number the final release will carry, as 3.0 clearly will cause breakage on older userspace.
will get released close enough to the 20-year mark, which is excuse
enough for me, although honestly, the real reason is just that I can
no longe rcomfortably count as high as 40."
After much discussion we decided we bite the bullet and upload a 3.0 kernel. At least we get a chance to identify problematic applications, while still keeping our options open to move to a 3.0.0 kernel for release should that be prudent. As expected this was not smooth sailing, not least for the kernel packaging which needed much love to even correctly build this version. Plus we had to hack the meta packages to allow that to be reversioned later too.
Once successfully uploaded the problem applications started to crawl out of the woodwork:
- depmod -- the depmod incantion to create the module dependancies identifies the kernel version in its command line but was assuming that a version contained three digits, this lead it to miss the version entirely and rebuild the wrong dependancies;
- libc6 -- both the runtime and the installation control scripts manipulate the kernel version number, in both cases assuming the version was three digits, enormous fun getting the pending updates installed;
- ps/top -- when starting the kernel version was checked, and miss decoded triggering a rather nasty sounding version warning whenever they are started;
- nfs-utils -- when attempting to read and identify the kernel version the nfs-utils would trigger a SIGSEGV and die, triggering boot failures on machines with NFS roots; and
- lm-sensors-3 -- this package is only compatible with 2.6.5 and above, failed version detection lead to this test failing and sensors being unconfigured.
Those are the ones we have found so far, I am sure there will be more. If you do find one please file a bug against the failing package but tag it kernel-3.0 then we can find them.