Re: Debian desktop -situation, proposals for discussion and change. Users point of view.
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
Reply to: