On Wed, Aug 02, 2006 at 03:31:54AM +0200, Luigi Gangitano wrote: > Il giorno 02/ago/06, alle ore 00:34, Steve Langasek ha scritto: > >It shouldn't have to be; the consequences of installing a package > >depending > >on 2.6-specific features onto a sarge system running a 2.4 kernel > >are clear, > >and any package maintainer should be ashamed to ship a package with > >etch > >that silently breaks the package on upgrade instead of providing a > >proper > >upgrade path. > I could not find any statement on what would be the upgrade process > from sarge to etch. This is why I asked on debian-devel for advise on > how to resolve this issue. > 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> I realize this particular message was posted to d-d-a after the thread in question, but I don't see that it should come as a surprise to anyone -- least of all Marco, who as I said is certainly in a position to know the problems we face with the sarge->etch upgrade path. (The only other comment in that thread saying it was ok to drop 2.4 support was from Moritz Muehlenhoff; but you also got feedback from Stephen Gran and Mark Brown, saying that a runtime check would be preferable.) > If this is the case etch will require an upgrade process involving > the kernel update before any user-space update. That's absolutely out of the question. Most systems will be unbootable when trying to upgrade to a 2.6 kernel before upgrading any of the userspace. And while it's *possible* that we could say "install busybox-cvs-static, upgrade glibc, and install udev and initramfs-tools, but don't touch slapd, squid, or rageircd; install the 2.6 kernel; reboot and continue the upgrade", I have two problems with that: first, it's much more complicated than I think any Debian upgrade should be considering that users don't actually read the release notes before upgrading, and second, I have no faith in this upgrade path remaining intact until the release of etch given the current approach of our kernel team. > If this is not the case, I'm left with no option to include the much- > better performing epoll() support in squid I realize this isn't an answer that's likely to make you happy, but yes, given those choices I think it's better to disable epoll() entirely. It may not be the most whizz-bang option, but with the current release cycles Debian can't win at whizz-bang anyway. Where it *can* win is on being solid, and solid upgrade support is part of that. > since upstream is not willing to integrate a runtime check in the short > term and I cannot support such an intrusive unofficial patch (which, BTW, > does not exist at all ATM). 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? > Since you are the one that has the last word on this, should I revert > this change until etch+1? I only have the last word on it if I make it a release critical bug, which as I've said, I'm not sure I want to do. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature