Nathanael D. Noblet wrote: > On 03/02/2010 06:06 PM, Björn Persson wrote: > > Jesse Keating wrote: > >> On Wed, 2010-03-03 at 01:34 +0100, Björn Persson wrote: > >>> Kevin Kofler wrote: > >>>> Even bugfix releases of KDE require a session restart to fully work. > >>> > >>> I consider that a serious design flaw in KDE and a strong argument > >>> against releasing any KDE updates to stable releases other than fixes > >>> for serious bugs. The only practical way to keep up with the Fedora > >>> update firehose is to update every day and let the update run in the > >>> background while I'm working. If I put it off until I'm about to turn > >>> the computer off, then the updates will accumulate and updating will > >>> take a long time when I finally do it. I might not have the time to sit > >>> around and wait for the update to finish so that I can turn the > >>> computer off, so I'll put it off again, and when the next opportunity > >>> comes the list of updates will have grown even more. That's a vicious > >>> circle I don't want to get into. > >> > >> We do need a "apply all updates and shut down" option. > > > > That doesn't help much if I'm going to pack the laptop up in a bag and > > take it with me. I'll still have to sit there and twiddle my thumbs > > while it updates. > > I wonder if something like the windows download updates and inform me > when you've downloaded them crossed with the pre-upgrade type system > could solve your use case. You mean the system would download updates while I'm working but I would have to wait while it installs them? That's of course a little better than waiting while it downloads them too, but in my experience the installation phase usually takes longer than the download phase (even without deltaRPMs), so it would only be a small improvement. Perhaps stuff like KDE and Mozilla could be tagged with a "breaks on update" flag in the spec file? Then only the "apply all updates and shut down" option would update those packages, but non-breaking packages could still be updated on-the-fly (as long as they don't depend on a breaking update). That should reduce the thumb-twiddling to a minimum while preventing unpleasant surprises, and also provide an incentive for packagers to try to make their packages capable of updating on-the-fly. Björn Persson
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel