On Wed, Mar 21, 2007 at 04:42:15PM +0100, Frans Pop wrote: > > However, users running with 2.6 kernels in Sarge and upgrading, might > > encounter issues with udev (it does not support versions prior to > > 2.6.15 and sarge provided 2.6.8), as described in #325568 (Upgrade path > > for udev needs documenting).
> This is not essential as long as you don't try to reboot before a new > kernel has been installed. My concern here is: what happens if an upgrade is interrupted in the middle, due to such things as a power outage, hardware failure, two admins not communicating with one another, or admin confusion about the state of the upgrade? Is the system recoverable at every point during the upgrade process, without extraordinary measures? > And even then my tests have so far shown that the system will probably > still boot (though X may not start). And will the networking necessarily start? That could be a problem for a number of users if it doesn't. > > It has been reported (in #396331) that a userland upgrade without > > upgrading first the kernel would remove the *running* kernel. This was > > fixed in aptitude 0.4.4-1 (bug #386307) which was allowed into testing. > > (Is a newer release going to be accepted, BTW?) > This can be avoided. Sorry, what can be avoided -- upgrading userland before the kernel? Per bug #413458, I don't think this is true? > I've just found a relatively straightforward way to upgrade a desktop > system that also answers the kernel/userland question. Actually, there > are two methods. > A. For those comfortable with interactive aptitude I'm glad that interactive aptitude will provide a way around this (it almost always will), but I don't think that alone is an adequate recommendation for the release notes. > B. Upgrading from the command line using mostly apt-get And apt-get has different bugs (#410695), doesn't honor recommends, and hasn't been what we've been recommending users use for upgrade testing for the past months... We can't flip-flop the recommended upgrade procedure every time we find a bug affecting one tool but not another. What do you think about the fam NMU we discussed? > - openbsd-inetd > - pppoeconf > Note: I confirmed that some of these (the last two) are because of #411123 > which makes me feel that aptitude 0.4.4-4 really _should_ be allowed into > Etch! Hmm. I'm provisionally amenable to accepting aptitude -4 into etch, but this is obviously a quite late change that will receive little additional testing before the release; so I'd like to hear what the other members of the release team have to say about this. In particular, is this fix one that would be worth delaying the release over if we find that -4 introduces regressions or requires further testing for purposes of the release notes? 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. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
