Ruarí's thoughts

If you can't wait for the Arch community repository, Slackbuilds (or the Salix repository) to update, you can download Opera 11.51 here.

Read more...

I started mentioning and sharing some of the packages that I have been auto-generating for my own use, hence I figured I should provide a blog post to give anyone who might stumble across them a place to comment or ask questions.

Read more...

Some people who have read earlier entries of my blog will know that last year I switched to Arch Linux (after a brief run with Arch variant Chakra). This was only for my main work install. I obviously run several distros for testing, either as local virtual machines under Arch or using various physical test machines scattered around our office.

My attraction to Arch was that I wanted to run a fairly stable but bleeding edge distro. This would mean that I would be one of the first to notice any problems caused by the latest libraries. It also appealed to me that the distro is fairly 'simple'. That last point always seems to need some clarification. Arch is simple from the viewpoint that it is easy to get your head around how everything works together (and hence quickly understand issues if things do go wrong), rather than 'simple to install' for a new user, like say Ubuntu is.

I have enjoyed Arch since I switched and generally it has given my less problems than other distros I have used previously. I have had one or two minor hiccups after big upgrades but nothing that wasn't easy to resolve with just a little reading on the Arch forums or Wiki. Because it has been so straightforward I also switched a couple of other machines. My main home machine and a VPS/VDS that I use for various types of hosting and as a '$HOME away from home'.

Six months or so ago I decided to switch my home machine to something else. I didn't need the bleeding edge, 'latest and greatest' packages and I'd prefer not spend the bandwidth constantly downloading updates I didn't really care about. After a quick look around I decided that Slackware would be my best bet. It has its little quirks with regards to packaging that put some people off (though most of the so called 'issues' can easily be worked around if you care) and it only has a relatively small collection of applications in its main repository but neither of these things really bothered me. The key thing from my perspective was its strong reputation in stability and the fact that it shares much of the same philosophy of Arch in its approach to 'simplicity and ease of use'. Once again this is not really about pleasing users who are new, inexperienced or just want something that works 'out of the box' but rather about making it easy for intermediate/advanced users, or those who want to learn a little about how parts of the OS work together.

Read more...

Download the latest stable build from here. The website should help you select the right package. You should also check if your distribution already offers Opera directly in their own repositories, many do for example Arch, Gentoo, LinuxMint, openSUSE, Pardus, Salix, etc.

If for some reason you are getting the packages directly from the Opera FTP server, downloading an Opera Next snapshot (development build) from the Desktop Team Blog, already have local copies of the packages or simply use a distro that is not listed and does not provide Opera directly within its repositories, here is a guide to help you match the package to your distro of choice, along with some installation instructions.

Read more...

Edit: If you just want to remove your preferences read this.

From time to time I get requests from users for help uninstalling Opera. Whilst we would obviously prefer you didn't do this , it can be a legitimate problem for users of our older tar packages and something I have written about briefly before. The difficulty is that although a list of files is echoed back during installation, we didn't used to provide any uninstaller with these packages.

Another reason you might want to uninstall Opera is that it is a sensible idea to remove old installs made by the Opera tar package install.sh script, prior to upgrading to more modern versions of Opera 10.51 and above. This avoids the potential for upgrade issues caused by our changed tar install procedure from this point onwards.

Below I will explain how you could manually remove a copy of the Opera Linux 9.64, 10.00, 10.10, 10.11 or the 10.20 desktop widgets labs release (and possibly older versions but I haven't checked) that was installed via the Opera supplied install.sh script.

Read more...

^{Disclaimer: I should start by stating that the text below represents my personal thoughts, and not official Opera policy. Working in the Opera testing department I often have to try out a range of different Opera builds on a number of different distributions, requiring various installs, uninstalls and upgrades. Depending on what issue I am testing at the time, I make use of a number of different methods for install. Some of the reasoning I touch on below. Wearing my employee hat for a moment the official recommended install and packages for non .deb/.rpm based Linux distributions, are the tar packages.}

Recently I saw the following comment from a Gentoo user on our snapshot blog:

Originally posted by DmitryIsaenko:

I don't actually know, where I can ask it.. but where I can get Gentoo overlay for Opera 10 or just ebuild for my OS?

Currently we only provide and support four package types for our Linux/UNIX users: .deb files for users of Debian-based systems (including Ubuntu), .rpm files for users of distributions like Redhat/Fedora, Suse, Mandriva, etc., .pkg files for our Solaris users and tar files for testing and users of all other systems. Even with the tar packages, these are fairly generic packages and not overly tailored to specific distros (e.g. they don't contain an install/ directory, with slack-desc and doinst.sh files for Slackware users).

We don't do this because we like users of other distros less but simply as an attempt to keep things manageable and keep the quality high, given naturally limited resources. The binaries contained within the provided packages are engineered to work with as many different distributions as possible. Indeed Opera fans often use them as a base to create new packages that work more naturally with their distribution of choice. Something we are very thankful for by the way! However, understandably this tends to be done only for big releases as it is entirely dependant on the time and dedication of the independant maintainer.

So ... What are users of non .deb/.rpm distributions supposed to do if they want to try out our snapshots?

Well, there are a couple of options. If you just want to do some quick testing, use the tar packages. If you want to install Opera then use the .... umm ... I'll get to that later, as I don't want to put you off so early in this blog post!

Testing a Snapshot: Part 1

If you just want to try the snapshots and don't intend to replace your main Opera installation, then you could make use of the third method I outlined in an earlier blog posting. You just need to ensure you already have the required dependencies pre-installed. On a modern (and up to date) distro the only one you are likely to have to worry about too much is the Qt toolkit. Install this via whatever method is appropriate for your distribution. Then download one of the tar files to an appropriate directory, extract and run Opera 'in place'. Here is a quick recap of how it is done, using the opera-10.00-4502.gcc4-shared-qt3.i386.tar.bz2 package as an example:

$ wget http://snapshot.opera.com/unix/snapshot-4502/intel-linux/opera-10.00-4502.gcc4-shared-qt3.i386.tar.bz2
$ tar -xjf opera-10.00-4502.gcc4-shared-qt3.i386.tar.bz2
$ rm opera-10.00-4502.gcc4-shared-qt3.i386.tar.bz2
$ cd opera-10.00-4502.gcc4-shared-qt3.i386
$ ./opera &

Note: This assumes you have installed Qt3 on Intel architecture (i386 or above). Alter the command as appropriate if you have a different version of Qt installed or use a different processor architecture.

In all likelihood this will 'just work', in which case skip to 'Testing a Snapshot: Part 2' of this posting (below). If it doesn't run try another package (e.g. gcc3 if gcc4 fails). If you continue having trouble and want to see a list of dependencies, run the following command within the extracted directory:

$ find . -print | grep opera.opera | xargs ldd

Once you are sure you have all the dependencies in place, try again.

Testing a Snapshot: Part 2

As I highlighted in my earlier blog post, running Opera in this way will cause a new 'clean' settings directory (profile) to be created as a subdirectory of opera-10.00-4502.gcc4-shared-qt3.i386 (i.e. opera-10.00-4502.gcc4-shared-qt3.i386/profile). If you would prefer use your main opera profile you can specify it with the '-pd' switch, changing that last line to:

$ ./opera -pd ~/.opera &

Note: This will however upgrade the main Opera settings/profile directory to a 10 style profile. If you intend to go back to Opera 9.64 then back up the directory first (see Method 1 in the that previous blog post if you are unsure how to do this).

Installing a Snapshot: The Background

If you really want to install an Opera snapshot, without first creating a distro specific package, then use one of our .rpm packages. Yeah, I said it, even though I know this will sound painful to the ear of many a Gentoo or Slackware user! Don't run yet, read the rest of this section first to at least understand my reasoning!!

Why the .rpm files? Well you could use one of the tar packages as they included an install script (called install.sh). However installing via RPM has one major advantage; it includes an easy way to uninstall. We have not yet written an uninstaller for the install.sh script. Therefore, doing it that way would mean having to manually remove all the files if you no longer wanted that copy of Opera. That isn't really very convenient for a release version (indeed we have a bug in our database about this: DSK-162946), but is even less ideal for snapshots given their nature (they receive very little internal testing). And why not the .deb files? Well sure, you could use these. I suggest the .rpm files because they are supported by almost all modern Linux distributions, even if the .rpm format is not used as the main package file format for that distro. This includes both Slackware and Gentoo, along with a multitude of others. In fact it even includes Debian based distros like Ubuntu! Now, I am not suggesting or advising you use the .rpm files for an Ubuntu install (though you could, I have tried it), I'm just saying it is possible!

If you are wondering why .rpm support is available on so many distributions I suspect there are two reasons. Firstly, the .rpm-based distros' historic dominance of the Linux landscape for a number of years (prior to the rapid emergence of Ubuntu as 'most popular distribution') meant that it was a very popular format, and therefore many other distros included it for the sake of compatibility. Secondly, the .rpm format is actually the Linux Standard Base (LSB) standard format. Distributions don't need to supply the RPM Package Manager to comply with LSB but they do need some way to deal with .rpm package installs (any package manager or package conversion tool that supports .rpm will suffice). That said, my own quick checks seem to show that the 'RPM Package Manager' is readily available for all major distributions, so I will use it in my installation examples below.

Note: If your distro of choice does claim LSB compliance but does not offer the RPM Package Manager, you will need to find out which package manager or conversion tool is supplied to deal with the .rpm format and do your own investigation of how it works.

Installing a Snapshot: Examples

Using the RPM Package Manager on a distribution that doesn't use it as the default package manager, means one of its key features doesn't really work that well. That feature is dependancy resolution. But if you are a Slackware user you will know that dependancy resolution is for wimps anyway! Also, you can still make use of the RPM Package Manager's dependancy checking, to help ensure everything is already in place prior to install, and to make sure you selected the right .rpm package in the first place. Here is the command to list a package's dependencies, using opera-10.00-4502.gcc4.shared.qt3.i386.rpm as an example:

$ rpm -qRp http://snapshot.opera.com/unix/snapshot-4502/intel-linux/opera-10.00-4502.gcc4.qt4.i386.rpm

You probably won't have to worry about this too much however. If you already found a tar package that worked for testing in the 'Testing a Snapshot' section above, just pick the equivalent .rpm package. Look at the numbers of the 'gcc' and 'qt' parts of the file name for the tar package that worked for you, to find the equivalent .rpm package.

After you have installed the RPM Package Manager on your distribution of choice, and made sure you have the right .rpm package and the required dependencies all in place, switch to root and install it as follows:

# rpm -Uvh --nodeps http://snapshot.opera.com/unix/snapshot-4502/intel-linux/opera-10.00-4502.gcc4.qt4.i386.rpm

Or if you prefer 'sudo':

$ sudo rpm -Uvh --nodeps http://snapshot.opera.com/unix/snapshot-4502/intel-linux/opera-10.00-4502.gcc4.qt4.i386.rpm

Note: Before issuing one of the above commands make sure you have removed any copy of Opera that is already installed by either install.sh or a native package manager.

To uninstall, execute the following as root:

# rpm -e opera

or via sudo:

$ sudo rpm -e opera

There you go, I hope that helps some of our users on non .deb/.rpm based Linux distributions get involved in testing snapshots!

Finally, after 10 is out, if a trusted Opera fan creates a package for your favoured distribution, feel free to remove the RPM installed Opera (and the RPM Package Manager itself) and switch to that. Or if you want, you can keep using the .rpm files! Isn't choice great on Linux? Have fun!