Although I have not found the smoking gun that caused the 7.1 system to
hang after a partial (hung) upgrade of an application RPM. However, I
have found the item that was being upgraded: darktable from EPEL .
Evidently, the latest darktable required other components.
A second observation. I use the Mozilla suite from current stable
production (not SL ESR) release, including Firefox, Thunderbird, and
Seamonkey (the latter for the HTML editor integrated into the browser --
but I do not use Seamonkey email). When the upgrade created a new /home,
not reusing the previous /home that was preserved untouched, the upgrade
automagic install of firefox (ESR, of course) created a .mozilla in my
new home directory. Originally, I left that untouched but did a ln -s
from my oldhome .thunderbird to my new home. This created
instabilities. I solved this by: 1 in my new home directory with none
of firefox, thunderbird, or seamonkey "open", I did mv .mozilla to
dotmozilla and then a mv of both .mozilla and .thunderbird from my old
home to my new home . Things seem to be working. Do understand that I
do not manually modify any of these dot files; all were created and
manipulated by the various releases (none beta, all production) of the
Mozilla suite components that I use. What I observed could be artifacts
of the way the Mozilla suite maintains these files, or it could be due
to some of the configuration being kept by Mozilla in one file and some
in the other, requiring both to be mutually consistent. This is just a
word of caution. I have not studied the current source code for the
Mozilla suite and thus do not know the answer, only my empirical
observations.
The subject includes "pseudo-upgrade" because what the 7.2 upgrade seems
to require is a re-install, at least if something gets "broken" as it
happened in my 7.1 .
Yasha Karant
