On Wed, Aug 02, 2006 at 11:56:45AM +0200, Luigi Gangitano wrote: > Il giorno 02/ago/06, alle ore 06:18, Steve Langasek ha scritto: > >On Wed, Aug 02, 2006 at 03:31:54AM +0200, Luigi Gangitano wrote: > >>The answer (not only the one from Marco), was that etch will not > >>support 2.4 anymore.
> > "Kernel version 2.4 is deprecated and won't be shipped as part of > >etch, > > but user space applications will have to deal somehow with 2.4 > >kernels > > (because of upgrade path, local installations, ...)." > > > ><http://lists.debian.org/debian-devel-announce/2006/07/msg00005.html> > Could user application 'deal somehow' with 2.4 kernels making the > administrator aware that they will need a 2.6 kernel to work at all? When will you make the administrator aware of this that won't make the upgrade path ugly? - if you error out in the preinst, the old version of squid continues running, but the dist-upgrade will break in the middle - if you error out in the postinst, the dist-upgrade completes, but the administrator may then be looking at unexpected downtime related to trying to upgrade the kernel before squid will run again > >Why do you say that it would be intrusive? It looks to me like a > >simple > >change to support building more than one select interface at a > >time, and > >using the best one that works. If such a patch existed, would you > >consider > >applying it? > Squid has a comm interface with different modules (poll, select and > epoll on linux, kqueue on freebsd, etc) choosen at build time. I > agree with upstream that compiling more than one comm module takes a > big change in one of the critical section and they are not willing to > make such a change to a stable release. I dunno, the 538 line patch I have here to support runtime selection between kqueue, epoll, and select (as enabled) doesn't seem like such a big change to me. :) > In alternative a new comm module based on libevent could be added. > libevent would support both epoll() and poll() and is in debian as of > now. I don't have the skills to create such a patch, but would > happily propose it upstream and include in the debian package. Well, unlike the patch I just created, writing this would require understanding the APIs of both libevent and squid's internal comm interface. That would take a bit longer to write & debug, compared with just providing a basic plugin interface. <shrug> -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
