On Thursday 22 March 2007 00:22, Steve Langasek wrote: > On Wed, Mar 21, 2007 at 04:42:15PM +0100, Frans Pop wrote: > > 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. I don't have the answers to these questions. I have not tested with multiple NICs and don't think I can reproduce device renaming here. But yes, these are real challenges some users may face. I really don't see how we could prevent them, except for warning about the possibility and giving basic instructions how to deal with it. > > > 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 meant removal of the old kernel > > 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. Agreed. > > 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... See my new proposal for procedure 'C'. > 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? I have it ready and it does work, but procedure 'C' has a fairly simple workaround. IMO it only makes sense to NMU fam if mesa is done as well. > > - 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? The new aptitude has by now been tested fairly extensively in unstable (I've been using it daily on several machines). As we don't use the new aptitude with any upgrade scheme proposed so far, I don't think it impacts the upgrade procedure or the RN at all. I also doubt it will affect new installs, but I have not tested that yet. Doing so is trivial (netboot or businesscard install of unstable). I'm willing to do that and also check if #411123 is really fixed. Personally I think it is worth it.
Attachment:
pgpVwA2IkkLc8.pgp
Description: PGP signature