Can't install Opera 51 on Ubuntu 14.04 LTS

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.

A Former User

@huwanhsin
There are obviously many other browsers out there for someone looking a substitute for opera on an old distro, but

How many of them are built with a good browser engine like firefox's gecko or chrome's blink and not some webkit fork for qt/gtk? A good browser engine is the key feature that provides decent performance to today's web pages whose complexity is increasing every year.

How many of them draw their ui with a good toolkit like gtk or qt and not with today's really famous crap, electron, like vivaldi, min and brave do? For me, this is a major issue, because I refuse to use an app that uses a huge amount of libs and an engine ONLY to draw its ui and nothing more. The reason behind that is usually a lazy dev that does not bother to build the application's ui with a nice toolkit.

If you are disappointed by opera's decision to move forward and drop support for distros that use an older version of some lib, you are free to use chrome which depends on an even older version of libdbus than opera 50 used to. Keep in mind however that asking for support on an 4-year old distro is pretty much the same as asking for support for an os like vista, which is neither supported by chrome or firefox right now.

Kinda offtopic, but since qt4 was mentioned on this thread, ubuntu drops support for qt4 completely for the next year's release
http://news.softpedia.com/news/ubuntu-preps-to-remove-qt-4-support-from-the-archives-target-ubuntu-19-04-520351.shtml

bbatten

bbatten @leocg

@leocg I think the reason for opera's ubuntu 16.04 requirement is that it has version 1.10.6 of libdbus-1-3. Again, if the set of functions in that library that opera actually uses hasn't changed, then it seems that the version dependency could be safely left down rev. That would have the advantage of increasing the target population of installable systems, which I think opera would have in interest in maximizing.

A Former User

Opera 51 was released like ~1.5 months ago. If the there was someone really, REALLY interested to make it install and test it on 14.04, he would change the control file so as to list libdbus 1.2.x (or whatever opera 50 had) as dependency and install it.

But no. This thread has 30+ comments (and 4500+ views) at the time I am writing this. Most them are either mine explaining the obvious "why linux sucks as a desktop os" situation or others complaining with "but this browser does install" examples. Why? Because complaining is easier than admitting something. I even got a downvote from someone who can not accept how things are,

bbatten

bbatten

Well, I guess I'm really talking for the benefit of opera as a business. A quick look at Distrowatch shows that Mint, Manjaro, and Debian all are downloaded more than Ubuntu. In addition there are many other deb based distributions (my own is Devuan Jessie) that would seem to argue for anyone distributing on a Linux based platform to be interested in supporting.
So the takeaway is that downrevved dependencies help maximize the potential market. Hopefully the fine folks at Opera will incorporate that observation in evaluating dependency policy going forward.

... just one man's opinion, folks.

ygbourhis

ygbourhis @Guest

@jimunderscorep

I'm just replying from Opera 52 under Linux mint Qiana (Ubuntu Trusty)

To do this I did the following:

fakeroot
dpkg-deb -R opera-stable_52.0.2871.30_amd64.deb opera-stable_52
vim opera-stable_52/DEBIAN/control # Change to "libdbus-1-3 (>= 1.6.18)" and save
dpkg-deb -b opera-stable_52 opera-stable_52_trusty.0.2871.30_amd64.deb
exit

The repackaged file is here:
https://storage.fr1.cloudwatt.com/v1/AUTH_71c6d0f9c3eb4f5a95cebeae99f3b468/Opera_Repackaged/opera-stable_52_trusty.0.2871.30_amd64.deb

So now I confirm it works with "libdbus-1-3 (>= 1.6.18)" so could Opera devs learn how to package things as I mentionned before?

Hope this helps.

bbatten

bbatten @ygbourhis

@ygbourhis
Thanks for making the patched deb package available. Unfortunately, wget fails with this message:

Read error at byte 43323441/55094366 (The TLS connection was non-properly terminated.). Giving up.

In the meantime, over at Debian Repository Unofficial, you can follow the link to Google Chrome to download Chrome 65. Installing the deb package also creates an entry under /etc/apt/sources.list.d so that subsequent updates to chrome are enabled. Chrome 65 works fine under Devuan Jessie, and it is fast.

qazerr

qazerr @ygbourhis

@ygbourhis
your method works! thank you!

ygbourhis

ygbourhis @bbatten

@bbatten strange, have you tried with curl or with a browser?

curl https://storage.fr1.cloudwatt.com/v1/AUTH_71c6d0f9c3eb4f5a95cebeae99f3b468/Opera_Repackaged/opera-stable_52_trusty.0.2871.30_amd64.deb _o opera-stable_52_trusty.0.2871.30_amd64.deb