Bowhunter wrote:A little while back I read that someone had laid SM 2.x into their 1.1.x folder and then renamed a file so the existing shortcuts on the desktop would use it.
This sounds like a good method to me to avoid breaking stuff by messing w' SM as I did recently.
Would the person that did this repost the info? I've looked for your post but have been unable to find it.
I did it differently. SeaMonkey is capable of updating itself from the Mozilla repository, and I chose that option with the version bundled with Puppy 4.12, to upgrade from the one shipped with Puppy to the latest version of the 1.X branch, which was 1.18. There was only one problem: the Mozilla installer places SeaMonkey in /usr/local/bin, and Puppy's default install is in /usr/bin. I had two installs of SeaMonkey, and Puppy's menus pointed at the older version. My fix was to rename the SeaMonkey executable in /usr/bin, and create a new symlink to the one in /usr/local/bin, so Puppy would find and use it without messing with the menu system.
SeaMonkey installs an executable into /usr/local/bin, and the rest in /usr/local/seamonkey. Thre are a number of libraries SeaMonley must link against, and that's where they live.
SeaMonkey and other Mozilla apps have two locations to be concerned with: the location(s) in the file system where the progams and libraries live, and the location where your Profile lives. Your profile contains your bookmarks, configuration, cache, history add-ons and other things. When you upgrade a Mozilla app, the Profile is not affected. The new version of the program attempts to use the existing profile.
One thing
has changed dramatically. SeaMonkey 1.X used the XPIInstall infrastructure. SM 2.X switched to Toolkit, which is the same code that handles add-ons and themes in Firefox and Thunderbird. Personally, I'm grateful. I make wide use of add-ons, and it's ahrd to find stuff that still works in SM 1.1. Most developers can't be bothered to maintain two separate branches, or the complext code to let their extension install correctly in either infrastructure.
In addition, SM 1.X let you
install extensions, but provided no built-in way to
remove them, and it was possible to regally hose an SM installation. (A third-party developer later came up with a pair of extensions to do it.)
There's a pet of SeaMonkey 2.01 that installs the executable in /usr/bin, like the SM 1.1 branch, so I suspect the same issue will arise when an SM update is released. (Why the Puppy packagers couldn't set SeaMonkey to install in the default Mozilla location eludes me. /usr/local/bin is in the PATH, and Puppy's menus can point to it there.)
______
Dennis