Can't install Opera 51 on Ubuntu 14.04 LTS

ygbourhis

ygbourhis

I had no error message appart from that "opera-stable has been kept back" when running "sudo apt-get update && sudo apt-get upgrade".
So I uninstalled opera, and saw the "dependency is not satisfiable libdbus-1-3(>=1.9.14)" error.
I tried to reinstall opera 50, but now I'm with no availlable opera at all:

sudo apt-get install opera-stable=50.0.2762.67
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les NOUVEAUX paquets suivants seront installés :
opera-stable
0 mis à jour, 1 nouvellement installés, 0 à enlever et 0 non mis à jour.
E: Impossible de trouver une source de téléchargement de la version « 50.0.2762.67 » de « opera-stable:amd64 »

Could opera be decent and nice enough to keep the previous version available for download? because now I find myself with no browser and can not upgrade my distro before a while because my job requires a Trusty.

Thanks in advance.

A Former User

There you go. Grab the deb from here and install it manually

ftp://ftp.opera.com/pub/opera/desktop/50.0.2762.67/linux/

In order for this to work

sudo apt-get install opera-stable=50.0.2762.67

the repo itself should provide an older/different version of the package, but it doesn't, it only has the latest one

$ apt-cache policy opera-stable 
opera-stable:
  Installed: 51.0.2830.55
  Candidate: 51.0.2830.55
  Version table:
 *** 51.0.2830.55 500
        500 http://deb.opera.com/opera stable/non-free amd64 Packages
        100 /var/lib/dpkg/status`

ygbourhis

ygbourhis @Guest

Thanks a lot @jimunderscorep

If opera wants to cover older distro support, could a solution be to do static links of some libraries (i.e. of libdbus-1-3 in this case, with it's dependencies)?

I know this is not a thing to do for distribution packages, but for large diffusion of "proprietary" apps, it is usually better.
Modern computers have large enough disks to support a larger package.
Ideally, two builds : a statically linked and dynamically linked package should be proposed. And this is not a lot of hassle for developers to propose this because there are no backports required.
A lot of proprietary vendors propose full statically linked dependencies and therefore install almost everywhere.
However, I don't know if a static link of libdbus-1-3(>=1.9.14) would work with dbus from trusty, but it could be worth the test.
I can be wrong because I don't develop in C or C++ or whatever language opera uses...

e.g. I develop on openstack in python and at a time, when precise was not EOL but not supported by openstack, we where packaging new openstack versions with dhvenv (packaging a python venv and all python dependencies without clashing with the distro's older versions) so that we could slowly but surely migrate to trusty afterwards.
I now run pike versions of openstack horizon on Trusty servers without conflicts with the distribution's libraries thanks to python venvs (but now with kubernetes instead of dhvenv packages, but still have no clashes with the rest of the distribution's dependencies thanks to python venvs which "could" be regarded (in a ways) as equivalent to statically linked C(++) libraries).
Therefore I have no issues and no clashes with the distribution's own libraries. And no need for backports to match the distro's libraries (I only backport security fixes and certain features from trunk before they get released and with even more ease now because I do not even have to care an inch about the running distro's antediluvian packages anymore).
Go language can also build with every dependency statically linked. So why could opera not propose such "special" builds and one could chose the static vs dynamic linked package? Does opera's programming language not allow to do this? I know it's possible in C and C++ but again do not know what opera uses... Maybe your programming language and/or framework does not allow to do so?
Doing so would even ease your own development by caring less of the distro's "libraries", and requiring less backports. The downside is larger packages, but with nowadays' disks it's peanuts to care about this.

I can test a statically linked package on trusty if you provide me one on your ftp, and give you feedback whether it works or not. It's maybe worth the test.

Regards

metaltrabant

metaltrabant @Guest

@jimunderscorep: Maybe the distro left SMPlayer on an old version, but SMPlayer team itself did another repository just for the Qt4 builds, so they didn't left the users in shit with an old version. And yes, I complained to them on Facebook, and then they told me this.

If they could do this courtesy, then a million dollar company also probably could. As an end user, anything else just sounds like shitty excuses to me, sorry...

In the global market, the companies should be for the user, and not the other way around. I know it's idealistic, but still... If it would be a community-maintained open source software, then it'd probably be okay, if the user needs to be a bit more flexible, since there the developers kind-of making the software out of favour and passion, but Opera is in a different business.

And the main conclusion is, that I still have to remain on this old (and a bit buggy) version for another year, if I don't want to upgrade my distro 2 times within a year (now, and next April, when 19.04 LTS will come out). Or I have to change browser again, which I don't really want...

A Former User

@ygbourhis
As it seems, opera does not offer static builds, only deb and rpm packages. And these 2 alone are enough to cover a huge percentage of the distros out there, since most of them are either debian based (deb) or redhat based (rpm). Google does the same thing for chrome, microsoft does the same for skype (although it's not a real app but a crappy electron web wrapper) and so on. The rest of the distros have to literally extract the deb/rpm they want and repackage it for themselves.
And I said before, I completely understand your frustration. I have 2 closed source apps I can not install because of some lib. But that's how closed source works.

@metaltrabant
First of all, lts versions come out once every 2 years, not evey year as you think, and they get released on even years (2006, 2008, 2010, 2012, 2014, 2016, 2018 etc). There will be no 19.04 as lts in the same way that there were no 17.04 lts, 15.04 lts and so on.

About the ppa repos and whatever they host.
Launchpad.net (= the place where all the ppa repos are hosted) is nothing more than a place canonical provides for anyone who wants to call himself a "maintainer" and package something that, for any reason, does not exist in the repos. Canonical does not support anything in there and that is the reason the "maintainer" can do whatever he wants, literally, because there are no guidelines or rules to follow. He can skip a version of what he packages, he can package a development version and he can stop all of it any time he wishes and without any notice, because no one is forcing him to do it. And no package from a ppa can ever get in the main repos, thus the connection between ppa repos and the main ones is non existant.

The rest of the things I said about linux moving forward remains the same.

ygbourhis

ygbourhis @Guest

Thanks @jimunderscorep for your reply

Statics builds can be proposed as rpm and deb packages too. Some devs C(++) in my team already did this plenty of times, so it's just totally possible, and it covers even more distros by doing so, meaning more users and revenues for your company (deb and rpm are just packaging methods, and do not imply that you need to do dynamic linked builds. dynamic linked builds are just distribution "politics", and very useful for "open source" packages, but non static builds for proprietary software is mainly the exact case of a wrong way to go).

Concerning your proprietary app, if you make a "static" build on a distro having the library (some change in the Makefile to make static builds), and since it's statically built you can remove some "Depends" from the "control" file in the deb source ("Depends" does not need all that is used for "Build-Depends"), than it could probably install as a deb package and work on your older distro (the deb package would just have some extra Megabites in size because of the static built-in libraries). For rpms, you have an src rpm and an rpm, you need a distro with the dependencies of the src rpm to build, but need less dependencies for the built rpm.

So to sum it up, it is totally possible to provide deb and rpm packages with static builds. Meaning you do not need to change an inch the distributing method. With C(++) apps It's no more than compiler options to pass during compile time. No more than that. Just a tiny little ting to change in the Makefile used to compile, and dependencies to remove in the "control" file of the deb package source (some "Depends" to remove).
All that is required is to build the package on a distro providing all the "Build-Depends", but then it installs on all distros having the "Depends" matching, and the less "Depends" you have in the "control" file, the more distro's it installs on.

Most of what is compiled statically can be removed from the "Depends" section.
Some packages well crafted can then run on a distro which can't compile it
NOTE: it's the wrong way to go for "open source", (and against debian politics for distribution packages) but this is not the case of Opera. It's that the distribution packagers' job to do backports and etc... if they want to provide a dynamic linked package. It's not the proprietary vendor's job, unless you want to open opera's source code and put it on github (You would be loved for this )

Currently you are using an open source package building strategy for a closed source app, this implies less distribution compatibilities.

The only thing that can be blocking is that some "extremely badly coded frameworks" may (I don't know your development framework) not allow this. If your framework allows this (if it's decently and intelligently coded), development would even be easier for your team because you would not need to do backports depending on distro libraries, and could even use more recent libraries without conflicting with the distro's own libraries, and the build would still be packaged in deb or rpm whatsoever, this would not change the way end users install.

I've already seen some deb packages with a Build-Depends library not provided by the distro, but statically built in the package, working properly.
I've even seen some proprietary rpms when I was working in Mandriva (Mandrake Linux) which where build on proprietary libraries we did not even provide or have at all. The libraries where simply statically linked by the vendor during the rpm build (so we where not even able to build the rpm ourselves). And believe me : it worked.

So I don't understand why you have a full open-source approach in package building for a closed source app unless you intend to surprise us and make your code open source in a while

I'm just trying to help propose that you have more users (and if your revenues depend on your users, well, you know what it implies).

Kindest regards.

metaltrabant

metaltrabant @Guest

@jimunderscorep: My bad, my mind was just so focused on that both current LTS versions reach their end of support in April 2019, that it just seemed logical that then will be when the next LTS comes out. But of course, I know they're released in even years... silly me

So I'll have a look at the 18.04 LTS and might consider upgrading soon, even though I'd loose a year of support from 14.04, but still, it might worth doing it.

Just the endless time it takes to create a full backup of my entire system is mind-boggling... and never did a separate Linux upgrade on my dual-boot system, so I'm a bit afraid of it. And also, I don't really like the Plasma 5 GUI... and all for this just because of a browser... meh.

A Former User

If you are really bored of backing up stuff in order to reinstall, you should really consider a rolling release distro. I moved from ubuntu 6.06 lts to debian testing back in February 2008, I have made countless of installations and removals of packages and I only had to reinstall twice: once when I moved from 32 bit to 64 and once more when openshot made my system hang completely and f-ed up my filesystem.

As for plasma, no one is forcing you to install it. Just choose an ubuntu "flavor" with a different desktop enviroment. And keep in mind that the most important changes from 14.04 to 16.04 and newer are under the hood, e.g systemd is far better than upstart.

ygbourhis

ygbourhis @Guest

I agree that a rolling release distro is by far the best and if it was up to my personal choice I would install an LMDE (Linux Mint Debian Edition). I was even running Gentoo at a time, BUT, for "job" reasons, I need a distro based on our production servers versions to make sure that what I develop will run on them. And that's because I do server backend development. So a lot of us do not have the "choice..." But with the technique I explained above we where able to develop deb packages built on 14.04 LTS which could install and run on 12.04 LTS before it was EOS (because theyr where "static" builds). So it's possible.

A Former User

Have you ever thought of running the os of your choice on your main system and use a virtual machine for your job needs?

ygbourhis

ygbourhis

For my job needs I need to run virtual machines already (devstack : I run a mega huge virtual machine which itself will run multiple virtual machines) and concerning these virtual machines which I need (for my job needs), My job requires me to create and destroy them all the time. So I can't develop on VMs which I need to destroy.
So I need my machine itself for the development and the "builds".
I can't run another virtual machine just to develop while the other "cluster-like VM" is also running because I only have a 16Gb of RAM on may core i7 laptop (and devstack does not work with less than 8B of ram, it is in my case assigned 12Gb to 14Gb of ram since it will itself host multiple VMs. I need it since I develop on this: https://www.openstack.org/). And also my SSD drive will be saturated. I need to develop "while" I have this huge virtual cluster running. And aside from this I also have bigger clusters in data centers, but need to be able to work remotely even when I have no network available. reason why I need my devstack for tests before pushing modifications to the datacenters for wider tests.

I'm turning back the question now: Have you never considered Appimage for Opera builds? : https://appimage.org/ ?

And I'm sorry, but making a static build is easy so easy... that telling your users to use VMs because you do not know how to do static builds... well.. is kinda what it sounds like...

A Former User

I am not an opera dev or something similar, so I can not decide wether an appimage/flatpak/snap package is needed or not.
In fact, I am just a simple opera user, and definitely an advanced linux user, who is very chatty at forums of any kind. Bear with me

Btw, if you consider yourself unlucky because you can not upgrade to a newer version because of some vital lib, please check the next thread where opera can not even be installed without breaking an entire 18.04 system because of another lib.

ygbourhis

ygbourhis @Guest

Sorry, my bad, you sounded like an opera dev :o)
My apologies

If opera breaks the whole distro on 18.04, it looks a lot to me like opera would add a library which replaces the distro library... and this would never happen if opera was a single and unique .deb package statically build (and bringing no other dependencies). One more reason why opera devs should strongly consider static builds

Again, to not get mistaken, I'm strongly against static builds for distro packages, but definitely "for" static builds concerning 3rd party proprietary packages.

Kind Regards

bbatten

bbatten

Seems like, as long as the signatures of the libdbus-1-3 library functions opera actually uses are unchanged, and their semantics remain compatible, the dependency could be safely left downrev. In my case >=1.8.20 would work just fine even if the library was actually at - say - 1.9.14.

leocg

leocg Moderator Volunteer

This issue should be fixed in recent released Opera 52.

A Former User

Actually no, opera 52 still depends on libdbus 1.9.14 or newer, so the problem still applies for users of old distros

$ apt-cache show opera-stable 
Package: opera-stable
Version: 52.0.2871.30
...
Depends: ... libdbus-1-3 (>= 1.9.14),

You obviously meant the issue with libcurl3/4.

leocg

leocg Moderator Volunteer @Guest

@jimunderscorep Even those that follow the minimum requirements : https://www.opera.com/pt-br/download/requirements?

A Former User

I don't get you. Can you be more specific, please?

All the complaints made in this thread here start from one small change on the version of a lib that opera depends on. I think I nave analysed the "why" behind that change as much as possible on my posts above.
Opera 52 depends on the exact same version of libdbus that opera 51 was and that alone is what makes it impossible to install on old distros, so nothing has changed to all I say except for opera's (and chromium's) version number.

leocg

leocg Moderator Volunteer @Guest

@jimunderscorep As far as I know, they fixed that issue but the fact that you need at least Ubuntu 16.04 didn't change.

huwanhsin

huwanhsin

There are a lot of browsers in the market. Should Opera insist only supporting Ubuntu 16.04 starting from Opera 51, the only choice we users can do is to stay with Opera 50 or stop using Opera. I don't think Opera team will give in based on the small user base of Ubuntu 14.04.