On Thu, May 17, 2007 at 07:56:57AM +0200, Mgr. Peter Tuharsky wrote: > Yes, I have written it there too. Kernel is, IMO, the best thing to > upgrade few times during release cycle, with quite little risk.
Upgrading the kernel is quite high risk. Features come and go and change with each new kernel. Drivers break in some releases, although usually only for less common hardware that no one tested during the development of that release, or new features are added that require updated user space tools, etc. For example 2.6.16 and higher tag all netkey ipsec packets with a policy tag of 'ipsec'. Before 2.6.16 they didn't. So going to 2.6.16 or higher broke shorewall in sarge since it didn't know about the new policy, and it required a newer version of iptables since it too had to support this new behaviour. Do you think people with ipsec tunnels would be happy if it stopped working just because of a kernel upgrade added to support all the people who just have to have support for their latest machine in debian's stable release that was made before the hardware in their new machine even existed? > Yes, Debian was the last distro using Xfree86 I know. Of course the > transition was complex! Sure seems much better with x.org than xfree86 though. > That should be changed anyway, since security upgrades occasionally > break things too. Downgrades are in general imposible to do, unless you put in a lot of useless code that will never be used except when downgrading, which of course will be used so rarely that it will be full of bugs due to not ever being tested by anyone. Remember upgrades sometimes have to convert files to a new format. A new package can do this because at the time it was made, the maintainer knew about the older versions already made. If you try to install an older package, there is no way at the time that older package was made to know how to convert from a newer file format back to the old one. So to solve this you would now have to add some kind of downgrade feature to the scripts of the new package that could be called before going to an older package. Sometimes data is no longer used and dropped from a file format, or new stuff is added. If stuff was dropped how are you going to restore it on the downgrade? If stuff was added I guess you can just throw it away on a downgrade. But overall supporting downgrades requires a time machine and lots of generally untested support code. I wouldn't want to try to support that. Of course often there is no change to the data or config files, and you can simply install the old package again using whatever package tool you like to use by telling it what version to install. So unofficially downgrading is possible most of the time, but when it isn't, supporting it isn't worth trying. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
