Does firefox upgrades need some pre/post install love to close and restart firefox during upgrades

Christopher Beland beland at
Tue Nov 17 05:32:14 UTC 2009

On Sun, 2009-11-15 at 10:23 -0500, David wrote:
> But, sorry, I find it absolutely amazing that anyone, anyone that uses a
> computer of any kind, running an OS of any kind, would not think that 'I
> just did an update and *one* of, or several of, my open applications (as
> in running) were updated. Things *must* have changed in them so I should
> close and reopen them to avoid problems'.

Um, some users would reply to that, "What's an application?  My grandson
set up the Linux for me and I just use it to visit the interweb."

I don't think it's very user-friendly to put the burden on users,
especially non-technical users, to know which applications they are
updating and which libraries they are updating and what a library even
is, much less which applications depend on which libraries that might
now need to be restarted. 

> And that *really* applies to someone using a rolling update such as
> Rawhide.

One problem is that Firefox goes wonky even with updates in supported

I've certainly been burned by this problem even as a fairly technical
person, partly because of the expectations I have from experience.
Whenever a server RPMs gets updated, rpm usually restarts the service
for me.  Why wouldn't it restart Firefox for me?  When Firefox crashes,
it remembers the web pages I had open.  Why wouldn't it remember the web
pages I had open when it's updated?

Losing session data during an update I would see as a bug (or probably
multiple bugs) in Firefox.  This could be fixed, which would make
Firefox more robust generally.  Probably we still have these bugs
because they are hard to find and annoying to reproduce.  If Firefox
were capable of basically writing its current state to disk on cue and
restarting itself with no net access and no user-visible changes, then
it could be more safely kicked like a service.

As far as yum is concerned, the only really safe thing for it to do
right now would be to detect in advance whether any running programs are
going to be impacted by an update, and by default refuse to apply the
update if it finds any.


More information about the fedora-test-list mailing list