My OperaWhere can I download an Opera 10.50 rpm or deb?
Thursday, January 21, 2010 9:07:48 AM
You can't, or at least not yet [Edit: Ok now you can. Head over to this more recent post on Opera packages for Linux and FreeBSD]. In the New Year's blog post we said, "Because this is a pre-alpha release, we don't recommend you to install it over your existing Opera installation. This is why we are releasing only non-installable tarballs instead of installable packages.". Whilst this is true it is actually only part of the story.
Before I proceed, let me say that we hoped the above statement would be enough to put people off from asking about this too much, as we didn't want to fill up that post with a long winded explanation. However it seems that it didn't put everyone off as some users want .rpm and .deb packages of a pre-alpha browser that would entirely replace their stable browser.
Indeed, I have seen such requests in comments in that blog post, in 'bug reports' (despite not being a bug, since it is a known and highlighted issue) and also in the referral links in the logs of my blog (where users have used searches such as "download Opera 10.50 rpm or deb" and arrived at my blog).So what is the other reason that we don't provide .rpm or .deb packages for 10.50? In essence it is really simple. There are no .rpm or .deb packages for 10.50, or to be more accurate no usable packages. Since the packages don't exist we can't really provide them to you.
Long winded explanation:
This obviously begs the question, "Huh, why aren't there packages!?". Like several key parts of Evenes, the Linux packages are being rewritten from the ground up. This will mean better packages, with cleaner post-install and pre-uninstall scripts. They will fix several minor issues and have benefits for our internal build system. Whilst early versions of the new packages have been produced a few things have yet to be completed and further testing needs to be done. There is little point putting out unfinished packages that have not been fully tested. Any problems with packaging and installation have the possibility to wreak havoc with the system by wiping out files and/or leaving things behind on uninstall.
So what about the old packages, couldn't we stick Evenes (10.50) in the old Peregrine (10.00 -> 10.20) packages and supply those? Sure, we could and such packages have been produced (our build system rolls them out automatically by default for now). However, there are problems with using these packages for Evenes. The most obvious being that they have a Qt dependency. Providing such packages publicly would only lead to confusion about our plans and many users wouldn't know how to install them on systems without also installing Qt. We could tweak the old packages slightly but this still requires some work to integrate the tweaks with our build system and do basic testing. This is essentially a waste of time given other more serious bugs we have to fix, and more importantly the fact that these packages will be replaced shortly.
Actually, the one package that has been supplied so far (the New Year's build) is just the old style Peregrine tarball with a few quick tweaks done manually just before upload, i.e. removing Qt references and deleting 'install.sh'.
Why delete 'install.sh'? Because it has one of the issues that we want to fix for Evenes (that I alluded to earlier in this posting), specifically it lacks any uninstaller. Again this might raise eyebrows amongst some of our users, so I will explain. When install.sh was first created the lack of uninstaller was not deemed to be a major issue. It was, and arguably still is, fairly common for such install scripts to lack an uninstaller. This might seem odd but you have to consider who installs the tarball packages or how else they are used. Most users (and certainly the overwhelming majority of new users) would never install Opera via the tarball packages. They tend to be used either by more technical users directly or for repackaging Opera into another package format (manually or via Arch/PKGBUILDS, Gentoo/ebuilds, Slackware/Slackbuilds, etc. scripts). In the first case technical users often install to alternative locations (making removal very easy) or even when installed to the standard location, removal is possible if they pay attention to where files are placed (this information is echoed back on install). In the latter case (repackaging) an uninstaller is not needed as Opera can be uninstalled by a distro's native package manager.
This brings me back to why we deleted the 'install.sh' for the New Year's build. There was a concern that some users, particularly less experienced users (who would not normally bother with install.sh), might think that they have to 'install' Opera to try out Evenes. If such users where to use install.sh directly they could potentially end up with a version of Opera that not only replaced their main install but that they also had trouble removing later. Hence I hope you will agree it is better to cause a minor inconvenience to our more technical users than to potentially break many less experienced users setups.
Hopefully, this rather long post better explains why we only offered the packages we did for New Years. With regards to the future, for the next few UNIX snapshots the situation will likely be the same, we'll only be releasing non-installable tarball packages. We will have .rpm and .deb packages back long before Evenes actually releases but currently the priority is to get some of the more obvious key functionality working better, e.g. native skinning, drag and drop, fonts, etc.
Ruarí Ødegaardruario # Thursday, January 21, 2010 9:21:11 AM
Or if you don't have curl installed (but do have wget):
After the initial download, you only need the last two lines to run it in the future, i.e.:
Ruarí Ødegaardruario # Thursday, January 21, 2010 9:23:14 AM
tomassplatch # Thursday, January 21, 2010 9:27:54 AM
Unregistered user # Thursday, January 21, 2010 10:25:28 AM
Ruarí Ødegaardruario # Thursday, January 21, 2010 10:32:52 AM
arghwashier # Thursday, January 21, 2010 2:13:57 PM
Ruarí Ødegaardruario # Thursday, January 21, 2010 4:04:56 PM
However, whilst the change is relatively small in terms of it doing for a one off package that you build yourself, at our end it still requires cross distro testing to ensure this does not cause unforeseen issues. Also an update like this requires us to integrate these new rpms with our automated build system (which itself does some automated testing). Hence as you can probably imagine this it is not quite so trivial for us to implement in the short term. For the early Evenes snapshots there wouldn't really be any advantage in doing this when the tarballs already allow you to run multiple versions of Opera side by side.
With regards to the our future plans. We aim to reduce the number of packages. This avoids confusion. Hence per OS/processor architecture there would likely only be one of each type of package e.g for Linux = 1 tar, 1 rpm, 1 deb or FreeBSD = 1 tar. Time will tell if we achieve this.
Flexible installs that allow for alternative install and profile locations will be handled by an updated tarball package with a brand new installer. Using our own installer for flexible installs makes more sense in that it provides the possibility of asking questions during install about alternative locations, and yet only needs one tarball package, rather than one .rpm that installs to /usr and another that installs to /opt.
Anssi HannulaAnssiH # Thursday, January 21, 2010 9:05:16 PM
Originally posted by ruario:
BTW, did you miss my previous comment about not being able to redistribute custom opera packages, or is it just that you aren't allowed to talk about that? http://my.opera.com/ruario/blog/show.dml/4172743#comment13848141
Ruarí Ødegaardruario # Thursday, January 21, 2010 10:05:59 PM
To answer your question the license you refer to is the end user license (EULA). It is intended for users who run Opera. Different, licenses are possible on request as hinted at here within the EULA:
"You may not sell, rent, lease or sublicense the Software, without the explicit written consent of Opera Software ASA."
We have indeed made exceptions in the past for other organisations, which is why you find Opera included with some distros and on mirrors. If you would like to find out about redistribution licenses I can put you in contact with the relevant people (send me a PM).
Ruarí Ødegaardruario # Monday, February 1, 2010 4:43:55 PM
That all said (since it keeps coming up) for those that (for some reason that I cannot fathom) want to 'install' Evenes, it is possible even without .rpms and .debs. As I have stated elewhere, the currently provided Evenes (10.50) tar packages are the old style packages based on the specification of the G3 (gcc4-qt3) Peregrine (10.10 -> 10.20) packages, i.e. they have the same physical layout (though this is temporary and will change in the future when the new packages are made available). The only difference is the naming and the fact that we manually deleted 'install.sh'. So, if you had a copy of 'install.sh' you could 'install' it. Anyway, here is a little info from my own system to do with what you will
If you do 'install' 10.50, don't expect any support if things go horribly wrong. That said, here are some quick tips. Consider runnning the installer as a regular user. This will place the Opera wrapper Script in '~/bin', the binaries in '~/lib/' and the shared files in '~/share/opera'. Alternatively if the installer is run as root/sudo, install with a prefix to an alternative location. Both of those options will make cleaning up (uninstalling) at a later stage easier. If you do install as root/sudo with no prefix make sure any other copy of Opera is first uninstalled and read this if you need to remove 10.50 later on.