Scheme Outline

Oh dear!  Like all documentation projects, this one has languished.  There's always something better to do.

My only excuse is that I've been very busy having a hard time adapting my (defective) diabetes management strategy to cope with new medication and to be less defective in order to avoid hyperglycaemia and the peripheral circulatory and neuropathy problems that come with it.  I've also discovered that if you can keep your blood sugar in a narrow band around the target value of 6 mmol/L you come alive and function properly - for the first time in a few years for me.

What I really wanted to do with the Mozilla apps was move away from the ESR versions (which you would normally update via the update distribution process favoured by the producers of the distribution you are using) to using the versions distributed directly by Mozilla.  These are updated more often than the ESR versions, which means you keep up with developments and have to live for less time with any bugs that have crept in and bite you.

I evolved a simple scheme to do this based upon use of the systematised filenames used by Mozilla for the bzipped tar files containing each release of the firefox and thunderbird apps - these have (to date) always been of the form app-version.update[.patch].tar.bz2 where "app" is "firefox" or "thunderbird", version is the release number, update is the lower level release number and patch is an [optional] even lower level release number but not always present.
As with additional software I add to my systems I placed the folders in the /usr/local tree to avoid cluttering up the base system files in the main /usr tree, in this case in /usr/local/lib, and named them app-version.update[.patch] with root ownership and no write access for other users to protect the product files from accidental scribbling over.
To access the binaries, I replaced the symlinks in /usr/bin with these...

/usr/bin/firefox -> /usr/local/lib/firefox
/usr/bin/thunderbird -> /usr/local/lib/thunderbird

... which point to symlinks in /usr/local/lib which redirect forwards to the actual binaries in the release I'm currently using...

firefox -> ./firefox-43.0.3/firefox
thunderbird -> ./thunderbird-38.5.0/thunderbird

... so at update installation time everything that needs to be changed is in one place, /usr/local/lib, and in the event of a problem, rollback simply requires the /usr/local/lib symlinks to be changed to point to the executables in the previous version directories.

What existed before I started applying direct updates

The system I'm currently running on was built from scratch using Slackware a little over a year ago.

The ESR versions of both Firefox and Thunderbird are installed as part of the Slackware installation, in /usr/lib/firefox-24.1.0 and /usr/lib/thunderbird-24.1.0 respectively.  The base executables (/usr/lib/firefox-24.1.0/firefox and /usr/lib/thunderbird-24.1.0/thunderbird) are accessed via symlinks in /usr/bin...

/usr/bin/firefox -> /usr/lib/firefox-24.1.0/firefox
/usr/bin/thunderbird -> /usr/lib/thunderbird-24.1.0/thunderbird

The remainder of the firefox and thunderbird packages (additional executables, private libraries and other files required at runtime) reside in the /usr/lib/firefox and /usr/lib/thunderbird directories and various directories inside them, exactly the way you would get them if you unpacked an install/update kit tar archive from Mozilla.

This arrangement of private files in a containing directory around a main executable works well, especially as the main executable can obtain it's location from it's environment, and needs to be left the way Mozilla have arranged it.  Of course, Mozilla may also change the layout and actual files from time to time.

Updating Mozilla Apps in a Linux Environment

This blog is about installing updated versions of Firefox and Thunderbird obtained direct from Mozilla in a personalised Linux environment. The methods described probably aren't suitable for organisational environments containing many systems and where updates are taken from the maintainers of your Linux distribution.


I've performed these updates manually for quite some time, and only got around to scripting the process recently.  In some ways this is a good thing because it allows the process you use to be designed, tested and corrected as necessary before you start implementing an automation script.

To save boring you, I'll divide this blog into multiple posts covering these areas...

• What existed on the system before I started applying updates to it
• What I wanted the update process to achieve
• What you get in an update pack downloaded from Mozilla
• Rolling back an update if necessary
• Automating the process - what I wanted to achieve
• Automating the process - additional actions
• Automating the process - using the script
• Current version of the script
• Future development

Steve
10 June 2015