rpm --import https://people.opera.com/ruario/archive.key.2013
Posts tagged with "RPM"
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.
This blog post is primarily aimed at our intermediate to advanced UNIX users. If you are new to UNIX you may find this to be too much detail. However, if you are interested in packaging or just want to know a little bit more about what we changed behind the scenes read on! If you are a user of the install script bundled in the tarball packages, you should certainly read on as the changes are potentially biggest for you.
Most of this information is now dated. Please read Selecting a Linux or FreeBSD package and installing it instead!
We frequently get questions about which Opera Linux package is the right one to install. Typically this is more common when we offer up a snapshot or when www.opera.com/download needs updating to show the latest and most popular distro version. My colleague csant has covered this topic before. However, as it is been a while and a few things have changed I think it is probably a good time for an update. I would also like to talk a little about the reasoning for the different packages and why we suggest one over another for a particular distro user.
Firstly for those who just want to know what to download and don't care too much about the background here is the quick summary:
- If you use a recent version of a modern popular Linux distro, you want one of the builds that includes 'gcc4' and 'qt3' in the name. (OpenSUSE 11.2 users should use a 'gcc4' 'qt4' .rpm package).
- Consider which processor architecture you use. We offer three for Linux: Intel (also called i386 or IA-32), x86_64 (amd64) and PowerPC (ppc). If this means nothing to you then you are almost certainly using Intel/i386!
- What package file format does your distro use? We offer two native types: RPM Package Manager (these end with a .rpm extention) and Debian Packages (these end with .deb). For users with another package management system we offer .tar files, optionally compressed with either the gzip or bzip2 compressors. I realise some people may still be unsure which package management system is native for them, so here are some example popular Linux distributions which would use each type:
.rpm = ALT Linux, CentOS, Fedora, Mandriva, PCLinuxOS, Red Hat, openSUSE & Yellow Dog
.deb = Debian, MEPIS, Linux Mint, Ubuntu & Xandros (Eee PC)
.tar = Arch, Gentoo, Sabayon & Slackware
So assuming you running a modern and up to date distro, on an Intel/i386 processor and need Debian packages you would want: opera_XX.XX.XXXX.gcc4.qt3_i386.deb (where the X's are the build and version numbers). Make sense? I hope so!
Note: I have assumed that FreeBSD and Solaris users are able to figure out which builds they need for their OS version. However, if you are not sure please do ask below as I would be happy to help!
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!