Indeed, this is intentional and we were aware of it before we released 11.60. We do not officially support Centos 5.* and hence started XZ compressing the rpms to benefit the majority of our rpm users as it allows for a significant file size decrease.

That all said, Opera 11.60 will run on Centos 5.* at present. I recommend you uninstall Opera 11.52 via rpm and then install via one of the tar packages as follows:

wget http://ftp.opera.com/pub/opera/linux/1160/opera-11.60-1185.x86_64.linux.tar.bz2
tar xf opera-11.60-1185.x86_64.linux.tar.bz2
su -c "opera-11.60-1185.x86_64.linux/install"

Note: An uninstall script (called 'uninstall-opera') is provided that will cleanly and completely remove Opera should you ever need to do this.

Alternatively, you (or anyone else) is free to repackage Opera in an rpm with gzip compression and offer this in a repository for Centos 5.x users. Our license does allows for this.

I see that some of the other distros have already started repackaging Opera 11.60, e.g. here is Mandriva's rpm: opera-11.60-1.mga1.nonfree.x86_64.rpm. I haven't tested their package and I see that they use lzma compresion in their rpms (which probably won't work for you either), nonetheless it demonstrates that others do already repackage Opera. So if you must have an rpm (you don't need one as I explained above but I know some people feel strongly about these things), you might want to look around and see if someone has already repackaged for Centos 5.x or a compatible distro.

P.S. Other rpm-based distros that I recall repackage Opera include Mandriva, openSUSE, openmamba, the Russian Fedora community, and probably numerous others.

Originally posted by truhuynh:

Not supporting CentOS-5 means also dropping all the Red Hat Enterprise Linux 5 / Scientific Linux 5x users

True, however this is not a change in policy, just a change in packaging. Opera often works on 'unsupported' distros because we have tried to design graceful fallbacks. For example Opera can do desktop environment integration but if the Gtk or KDE libs are too old it will fall back to its own styling. Additionally Opera's dependencies are minimal comparative to our major competitors. So all the policy really means is that we won't make major changes to accommodate those 'unsupported' distros. At the same time many users run on them and that is obviously fine by us.

As to what our 'support' policy is, it basically breaks down as follows. For the most part we consider distros supported as long as their upstream provider also providers support them, e.g. right now some of the older distros would be Debian 5.x, Ubuntu 10.04 LTS, etc. However, one exception to this rule (as you have discovered) is that with 'Enterprise' distros we only support the latest version (not all the older supported versions). There are two reasons for this, firstly their libraries are often too old meaning they can't support Opera's full functionality (as it happens right now the only real downside on RHEL/Centos/Scientific 5.x is a lack of Gtk integration). Secondly, most desktop users will want to run the latest version of these Enterprise distros to allow them to run a bigger range of up to date desktop software. Sure, we realise that people such as yourself use Centos 5.x on the desktop but its biggest market is servers, where avoidance of updates is more critical. It is fairly trivial and relatively risk (and cost) free to update a desktop distro.

All that said, Opera will still run (often minus certain things like Gtk integration, HTML5 video support) on many older distros (I used Ubuntu 6.06 just last week and that distro was released on 1 June 2006), so for you this is only really a packaging issue.

Since we make a wider range of binary packages available than our competitors, with more flexible install options, you can still install and use Opera. You just have to switch to a non-native tar.bz2 package with the included install script. Or as I stated above, use a package created by the your distro or the community, just like you already do for probably ever other piece of software you have installed.

Originally posted by Frank-Steiner:

I really don't know who cares about 4 MB nowadays.

That is a quarter of the file size knocked off. It does matter to many people on slower connections and it matters to anyone hosting the files to multiple users.

That said, I take your point and indeed it wasn't our intention to break SLED 11. The best solution is simply for one person to take the opera.spec used for by one of the distros that does repackaging and adjust it to not use xz compression. Then it would be trivial to tweak the build and version numbers after each release and create a new rpm.

In the mean time, until there is a better solution I have repackaged the Opera 11.60 rpms for you myself.

@Frank-Steiner: When I get a spare moment I might try my hand at writing an opera.spec file. I don't generally work much with making rpms, though I have made a couple of test spec files before.

Unfortunately, the one we use internally is no good as almost all of it is generated on the fly for each build. Also it doesn't use the tar file as a source package as it can use the real source.

Ok, here is a quick opera.spec I knocked up. Go easy on me as I'm a bit of a novice at creating these and I am not the biggest rpm fan . Even if you need to change it I'm hopeful it will give you some hints, as I have tried to add comments throughout.

With a bit of luck you should only need to edit the first two variables when a new release comes out in the future. Another nice thing I do is have it pull down the correct opera tar.bz2 automatically and stick it in your SOURCES directory if it is not already present. This means you should just be able to issue the following:

rpmbuild -bb opera.spec

Or if you want to package for another architecture, try either:

rpmbuild --target i386 -bb opera.spec

or

rpmbuild --target x86_64 -bb opera.spec

Another SLE (SUSE Linux Enterprise) 11 user contacted us via our bug reporting system. He suggests that SLE 11 can use lzma compression within rpms. I am uncertain about this however as it was my understanding that RPM gained experimental LZMA support in version 4.6.0 and yet SLE 11 seems to include 4.4.2.3. Though it is of course possible that SUSE back-ported support or I simply have my facts wrong.

@Frank-Steiner (or anyone else using SLE 11): I have created test 11.60 (final) rpm packages with lzma and bzip2 compression. Could you check which ones work for you as I don't have a copy of SLE.

Opera 11.60 (final) 32-bit, with lzma compression
Opera 11.60 (final) 64-bit, with lzma compression
Opera 11.60 (final) 32-bit, with bzip2 compression
Opera 11.60 (final) 64-bit, with bzip2 compression

Ideally I would have us support the most highly compressed rpm that still installs on SLE 11 SP1.

Originally posted by screamingwithnosound:

no doubt he'll post an update when he's digested it and played with the modified spec file I sent him...

Indeed I probably will, when I find a spare moment. Thanks for all the feedback!

We will probably switch to lzma compression for a future release. This will allow backwards compatibility with SLE 11 SP1 (which we would like to support as explained above), whilst still allowing us to retain the small package size. xz is actually lzma compression with some tweaks so the file size is almost identical. We already do use lzma rather than xz for greater compatibility with our deb packages for exactly the same reason.

I'll also see if we can get the main 11.60 final package updated on our public mirrors with a repackaged version using lzma compression.

Off topic: Regarding RPM, I don't want to come across as some RPM hater. To be 100% clear my personal issues with it are really on the packaging/development side. Mainly because you have to embed yourself in the rpm world, since you have to use rpm tools to produce, query and manipulate rpms. This also leads to you not being able to really edit or tweak rpms after creation (they have to be recreated from scratch with the original spec or a new spec if you can't access the original). It also requires a fair bit of rpm specific knowledge to understand how best to make use of all the macros when creating an rpm file (they are powerful but potentially confusing). As a comparison I can edit (or even "hand craft") deb, slack, archlinux, etc. packages on any unix-like system using standard common tools should I so desire (though of course it is better and usually faster to use the real tools). But I like this type of flexibility and the fact that skills I have already learnt carry over more easily.

That all said, from an everyday user perspective, modern RPM and the various fancy front ends (zypper, yum, apt-rpm, urpmi, poldek, etc.) have pretty much the same power and flexibility as package managers dedicated to other formats. So these days RPM works well for most people. Indeed, I suspect that some of RPM's bad reputation actually relates to the past. Many users of Debian and derivatives mock RPM by choosing to compare it to APT but this is hardly a fair comparison. You either need to compare rpm to dpkg or APT to something like Zypper.

Originally posted by Ruohtula:

please support RHEL5 and its clones (CentOS 5, Scientific Linux 5)!

I wouldn't get hung up on if RHEL5 is supported or not. It already wasn't supported by us before 11.60 was released. This 'support' label just means we won't make major changes to Opera to accommodate such a distro. You are still free to run Opera on it and report issues that you might see. Also even if a distros is unsupported we don't go out of our way to break older distros intentionally. Opera still runs just fine on older distros than yours. As I said earlier in the thread I recently ran Opera 12.00 on Ubuntu 6.06, which was released over 9 months before the first release of RHEL/Centos 5 and although I didn't test extensively I noticed no major issues.

With regards to installation, yes we were aware that the new rpms would not install on RHEL/Centos 5 but this was not considered a show stopper because there are other installation options. The tar packages are provided as a fall back for every Linux user or you can repackage as I demonstrated above. Many Opera power users actually prefer the tar packages as they allow for more flexible install options (.e.g. multiple side by side installs, installations to alternative locations, making a portable Opera that runs from a USB stick, etc.). You should also keep in mind that for most distros we provide no native package at all, yet we have plenty of users on Gentoo, Archlinux, Slackware, etc. because third parties maintain repackaging scripts and often packages (FreeBSD similarly is not provided within a native package and is usually installed via their ports system). Even for rpm and deb distros we are often repackaged to better conform with distributions own packaging guidelines. So not having an Opera officially provided rpm that installs on RHEL/Centos 5 certainly does not mean the end of the line for Opera users on that platform.

We will try to get the official 11.60 rpms updated to use lzma compression on the main server today (and later the various mirrors should pick them up). This will allow them to be installed on SLED 11.

Originally posted by ruario:

We will try to get the official 11.60 rpms updated to use lzma compression on the main server today

done!

Originally posted by ruario:

Also even if a distros is unsupported we don't go out of our way to break older distros intentionally.

Originally posted by Ruohtula:

Er..., you just did! (by using the newer rpm format)

No, there are packages available from us that allow installation on RHEL5 (just not native ones) and Opera can still run on it.

Bear in mind that FreeBSD 8 is considered a supported OS but we do not provide a native package for it. So us providing a native package or not does not really relate to if we consider a distro (or OS in the case of FreeBSD) supported. Of course we prefer to provide native packages but it is not a prerequisite. Most software in the *nix world does not come prepackaged by the author in native format for all supported distros and OSes, rather you usually get one source package and distros and software repository maintainers produce native packages from that. Since we aren't an Open Source company we don't provide a source package but our tar packages with install script are the nearest equivalent. The debs and rpms we provide are just icing on the cake.

Furthermore the package change was not us saying, lets do this just to break RHEL5 rpm installation for the fun or it, rather it was an optimisation for the majority of our rpm using users that had this as a side effect. So I still hold that we don't go out of our way to break Opera on older distros intentionally.

Originally posted by Ruohtula:

On one fresh CentOS 5.7 it works, on a semi-updated 5.6 it crashes immediately.

What colour depth do you have set on that machine. You may be hitting this bug.

Originally posted by Ruohtula:

From my point of view this is an annoying regression.

We have a fix internally but it is still undergoing testing and code review. Nonetheless, seems likely we will have a fix by the time we release the next stable version.

@ocky: I presume you let the uploaded the crash log? If yes, pm the email address associated with it and I'll search for your last crash and take a look.

Originally posted by screamingwithnosound:

I work with RPM a lot (for my sins...) and have sent ruario some pointers on compatibility between different versions of RPM - no doubt he'll post an update when he's digested it and played with the modified spec file I sent him...

I must admit that I haven't found time to do this yet. However, I have since found an even simpler solution that anyone use could use to easily repackage the Opera rpm packages with gzip compression, allowing for installation on RHEL 5.7 (or Centos, Scientific, etc.).

http://my.opera.com/ruario/blog/2012/01/17/repacking-opera-rpms-for-use-on-older-distros

@domblogger: If you need to update those machines, there are links to repackaged rpms of 11.60 above