FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

Björn Persson bjorn at xn--rombobjrn-67a.se
Wed Mar 3 12:24:49 UTC 2010


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100303/24b04f99/attachment.bin 


More information about the devel mailing list