Ruari's thoughts

People often like to try new snapshot or beta builds of Opera but are cautious about messing up their main profile with a build that could be unstable. They need a way to get back to their previous state. I'll outline a few of ways this can be done. I won't list all possible ways, just three simple ones that I hope that most UNIX/Linux users could use without too much fuss. I should also mention that all of these methods have been outlined elsewhere both officially and unofficially, so I am not saying anything new here. If you are an advanced user don't be shocked if I teach you nothing new. However not everyone knows these methods and sometimes it helps to rewrite these things so that people get a more rounded idea of how it all works. Also by placing it on my own blog post, people can ask me directly about any part they are unsure of.

Method 1

The first method is as simple as they come (and should be done anyway, even when trying the other methods). The short version is: Backup your profile settings directory before you start testing!

If you are unsure about how to do this I'll explain (if you know how it is done skip to Method 2). By default the UNIX/Linux version of Opera stores its profile settings in the directory ~/.opera (where '~' refers to your home directory). To backup you simply make a copy of this hidden directory. This can be done via the GUI (graphical user interface) using a file manager such as Gnome's Nautilus. You just have to display hidden files first. In Nautilus this is done via 'View > Show Hidden Files' (or the keyboard shortcut ctrl+h). Similar options are also available under other file managers such as Konqueror or Dolphin. Simply copy the ~/.opera directory to something suitable like 'opera_profile_backup'. Alternatively on the command line you could issue a command such as the following:

$ cp -r ~/.opera ~/opera_profile_backup

Now you can update Opera to the latest test build and test away. When you have done testing either keep the new snapshot/beta, or if you want to downgrade then simply do so. If you suspect any issues with your profile following the testing you can restore it by removing the corrupted ~/.opera and renaming ~/opera_profile_backup to ~/.opera. Done ... simple!

Note: Before you can backup your profile settings you must shut down Opera first. If Opera is running you may not get a good backup as files made be in the middle of being altered.

Method 2

This is a slight improvement on Method 1 and as an added bonus it also a great way of testing if a suspected bug is really an Opera issue or some problem with your profile. Before you upgrade make a backup copy of your profile settings as outlined in Method 1. Just to be sure!

This method utilises the '-pd' switch. The '-pd' switch allows you to specify a different Profile (settings) Directory. As you now know, Opera stores its profile settings in the directory ~/.opera by default. To specify a different directory you simply follow the '-pd' switch with one of your choice and if the directory doesn't exist, Opera will create it!

To actually test a build using this method simply upgrade to the Opera package you want to test and run Opera from the command line using the '-pd' switch to specify a test directory, e.g.

$ opera -pd /tmp/opera_snapshot_test &

A directory called 'opera_snapshot_test' will be created as a sub-directory of '/tmp/' to house your profile settings.

If you wanted to test your current profile settings without messing them up, you could copy ~/.opera to /tmp/opera_snapshot_test first before running Opera with the '-pd' switch, i.e.:

$ cp -r ~/.opera /tmp/opera_snapshot_test
$ opera -pd /tmp/opera_snapshot_test &

When you are done testing you can delete this whole directory and either keep this build or downgrade as you see fit.

Note: Earlier I mentioned that the '-pd' switch can be used to test if a suspected bug is really an Opera issue or some problem with your profile. This is true because you can use it to specify a clean profile. Therefore, before submitting an Opera bug try testing first with the '-pd' switch set to some new unused directory.

Method 3

This is the cleanest and best method (in my opinion), as it does not require you to upgrade or even 'install' the version you want to test. Instead of using one of the RPM or DEB packages, download one of the tarballs instead. A 'tarball' is a tar archive, which is typically compressed with gzip or bzip2. Hence the relevant Opera packages will end with .tar.gz or .tar.bz2. The tar packages are primarily provided for users of distributions that don't use the RPM or Debian based package managers. These could be distributions like Slackware, one of the smaller cut down distributions like Puppy Linux or even a setup where an advance user has manually created their own install (such as Linux from Scratch). These packages require no package manager and include an install script to assist installation.

As no package manager is needed, these versions do not handle full dependency checking. That may sound like a problem but it really isn't. Typically everything will already be in place on a modern distro anyway. The only part that might be missing in some modern distributions is the correct version of the Qt toolkit. However even this is not such a problem. If you have installed Opera previously via one of the package managers then Qt will have been installed already. In which case you just need to know if it is Qt3 or Qt4 and then pick the appropriate tar package. Even if you don't know this, it still doesn't matter, just try the Qt3 version first and if that doesn't work try Qt4. If you are really stuck just pick one of the static or bundled packages as these include a copy of Qt, so that you don't need to install it! There is no real risk of picking the wrong version anyway as we aren't going to actually 'install' a new copy of Opera as you'll see in a moment.

The key to how this works is that in addition to the install script, another handy script is included with the tar packages. It is a 'wrapper' script that allows opera to run 'in place', without editing or updating files outside of its own directory. The wrapper script is called 'opera' and is in the top level directory of the untarred package. As no files outside of the test directory are touched, when you are done testing you can simply delete the whole directory to revert to your setup before you began testing. Cool eh?

It might help if I gave you an example. I will test in the /tmp directory. Here is how I could quickly test 10.00-4464.gcc4-qt4.i386 without messing up my setup:

$ cd /tmp
$ wget http://snapshot.opera.com/unix/snapshot-4464/intel-linux/opera-10.00-4464.gcc4-qt4.i386.tar.bz2
$ tar -xjf opera-10.00-4464.gcc4-qt4.i386.tar.bz2
$ cd opera-10.00-4464.gcc4-qt4.i386
$ ./opera &

This will start opera and the wrapper script will create a new (clean) profile as a sub-directory of /tmp/opera-10.00-4464.gcc4-qt4.i386 called 'profile', i.e. /tmp/opera-10.00-4464.gcc4-qt4.i386/profile

Bear in mind that although the wrapper script does not update any files outside of its home directory by default, you can force it to do so if you desire, e.g. if you wanted to test your regular profile you could do the following instead after the step of cd'ing into the opera-10.00-4464.gcc4-qt4.i386 directory:

$ ./opera -pd ~/.opera &

There isn't much point in doing it this way though as it would alter your main profile, which is the very thing we are trying to avoid! I just wanted to demonstrate that the '-pd' switch still works even when running the wrapper script. A safer way would be to make a copy of your profile first and test on that copy, i.e. after the step of cd'ing into the opera-10.00-4464.gcc4-qt4.i386 directory, you would do the following:

$ cp -r ~/.opera profile
$ ./opera &

Here are the full set of steps again:

$ cd /tmp
$ wget http://snapshot.opera.com/unix/snapshot-4464/intel-linux/opera-10.00-4464.gcc4-qt4.i386.tar.bz2
$ tar -xjf opera-10.00-4464.gcc4-qt4.i386.tar.bz2
$ cd opera-10.00-4464.gcc4-qt4.i386
$ cp -r ~/.opera profile
$ ./opera &

Then after I have finished testing I could do the following to clean up after myself:

$ cd /tmp
$ rm -fr opera-10.00-4464.gcc4-qt4.i386*

In this case not only was your main profile settings folder not altered, we didn't even have to upgrade the installed copy of Opera!

Ok, that is all for now. If you have any questions ask below and I'll do my best to help.