On Tuesday 15 July 2008, you wrote:Because in most cases users do not write and maintain the scripts used to build custom kernels themselves. They use (huge and way too) tools like Debian's 'make-kpkg' for that. Because users may want to build a custom 2.6.27 in for example a Debian Etch environment using the make-kpkg package that is available in that release of Debian. Or even a Debian Lenny environment (Lenny is about to be frozen so is very unlikely to include whatever may be needed for this). Why is it good to extend the lifetime of the i386 and amd64 symlinks for x86 images by an extra few years so that older versions of kernel packaging tools - like make-kpkg - don't break, but is breaking the exact same tools with this firmware change suddenly OK? Users _want_ to be able to build new kernels in older environments. Why take that option away from them? Why force them through the pain of partial upgrades of their userspace if it can so easily be avoided? From my PoV adding this option is a no-brainer: if Jeff is willing to do the work, then what harm can it do? The benefits to me are obvious. I really don't get what you have against it. Cheers, FJP P.S. Sorry to keep coming up with Debian examples, but that's the environment I know. --
| Pierre Ossman | Re: [RFC][PATCH] cpuidle: avoid singing capacitors |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Greg KH | Re: Announce: Linux-next (Or Andrew's dream :-)) |
| Rene Herman | 2.6.26, PAT and AMD family 6 |
git: | |
| Jesper Krogh | Re: NIU - Sun Neptune 10g - Transmit timed out reset (2.6.24) |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Arjan van de Ven | Re: [GIT]: Networking |
| Radu Rendec | htb parallelism on multi-core platforms |
