Can't install due to dependencies

A Former User

I have an older distro version and I am getting a message like others talk about in this missing dependency post. It was locked, so could not ask about it in there, and probably better to do a new post on it, since it is a dependency for a different library (not even giving me a problem about gtk-3.0 or whatever they were having, maybe I have just not got far enough into the unsatisfiable hell I forsee I might be entering into trying to get Opera to run.

The message I get is that libgbm1(>=17.1.0~rc2) is the unsatisfiable dependency. Will the same fix that worked in the linked post (by user kmod ) I put in above work on this i.e. I change that control file for a lower version of that library? Or is this libgbm1 library something that is definitely required at that version level or above in order for Opera to run correctly? Linux newbie here, so I don't really know how to tell if a library is required to run or not. I don't even know how to check which version of libgbm1 I am running, so that I can know what level to replace it with in that control file if that is even a working solution in my case. Where would I look for llibgbm1 to check what version I am running? Thanks for any help anyone can give me

l33t4opera

l33t4opera @Guest

Hi @ridgerunner, I think it's waste of time doing that, because when a new version of the package arrives, you will have to do it again, and again when another one will be populated and so on.
Perhaps it will be more easy/less time consuming if you simply unpack the files manually from the package, or use "alien" tool to convert it to TGZ and unpack the files from it. Please be aware, that you need to do this every time when a new version arrives. Of course until the time such issues are fixed, which is unlikely because really old distros are not supported by Opera - meaning that the issues are resolved rarely or leaved unfixed at all.
After that, you should be fine - I mean the Opera should run without big problems.
The libgbm1 package includes GBM buffer management library. It provides a
mechanism for allocating buffers for graphics rendering tied to Mesa.

By the way: maybe you can provide more details about your OS: name, version, specific setups/settings etc., which can be helpful for others trying to help you.

A Former User @l33t4opera

@l33t4opera :
Hi, it is even more messed up that that. The user fibo talks about the problem in a post in this blog about an earlier update to Opera for Linux when he started running into this error message. look for the post by filbo. The Devs have their RPM packager or whatever set up properly and the manifest for it only calls for libgbm1(>=8.0~) a MUCH older version of it which should work on any version of ubuntu back to like 9 or 10 and any version of mint back to like 10 or 12 or whatever. He talked about how he was able to change the manifest file in the deb using Alien and set it to this older version and bada boom bada bing, ran like a Singer sewing machine! Then he kindly asked the Opera Devs to correct this little problem with their Deb packager or whatever asking for the wrong much newer libgbm1 library or above and change it's manifest to only ask for 8.0 version or above. Obviously the Devs have not got around to that one simple change he asked for 5 months ago. They just need to go in and fix that requirement in the manifest (or whatever) of their Deb compiler or packager or whatever to match what their RPM packager or whatever is asking for - a much older version of this library.

So if this is the case, that it only needs libgbm1(8.0~) instead of 17 does this mean I can use kmod's workaround about just editing that file to ask for only libgbm1(8.0~) and that will work to let me install it from the deb? Thanks

l33t4opera

l33t4opera @Guest

@ridgerunner I understand, but as I told you already, the Opera doesn't support really old distros or they have other, own reasons to not doing that, and therefore most probably they will not change the required version to the lower one.
However, the Opera's peeps sometimes read post on the forums, so you can write here, that you require such of change, and perhaps maybe they will do an exception in this case.

Of course you can do what you want, even modifying the manifest as you said, but as I told you, it's not worth it, since you need to do it every time a new version arrives. Firstly, I would rather unpack the files manually, launch the Opera and check if it works without big issues or not.

A Former User @l33t4opera

@l33t4opera said in can not install, dependency unsolvable (not gtk>=3.0 or whatever):

@ridgerunner I understand, but as I told you already, the Opera doesn't support really old distros or they have other, own reasons to not doing that, and therefore most probably they will not change the required version to the lower one.
Of course you can do what you want, even modifying the manifest as you said, but as I told you, it's not worth it, since you need to do it every time a new version arrives. Firstly, I would rather unpack the files manually, launch the Opera and check if it works without big issues or not.

OK, I see where you are coming from, but if you go over to that blog post by filbo on the comments for the release of a new version of Opera for Linux where the Devs had been talking about all the improvements and patting themselves on the back, you will see, as far as I can see and it seems pretty obvious to me even as a newbie, that what filbo is saying that it is not a problem with the build not supporting older versions of the distros it is a problem of their Deb packager not doing up the manifest or whatever right compared to the RPM packager, not that it won't run on his system after he makes that change. It does run on his system after he makes that change to the deb manifest using alien.

Pretty much the same thing kmod is saying in his post in the earlier forum thread here about this problem. kmod says in his post as well that he unpacked the files and put them in Opera directory and it ran fine. Then in kmod's 2nd post he said that it was just easier or better or something to unpack the .deb and change that requirement in the manifest to a lower one and then gdebi or whatever deb installer one uses will work fine to automatically install it and it runs fine after he does so.

So I think we are passing each other by here in this discussion. From what I am reading about this, the Devs don't need to change a bunch of libs or binaries or do a total rewrite of Opera trying to get it to work with old distro versions. All they have to do is make sure that for the requirements in the Deb packager manifest for these libs (libgtk3 for some people, in my case and others libgbm1) match the manifest version requirements in the RPM packager.

At least that seems to be what I am seeing as the problem here. The lib version requirements just have to be changed in the manifest or whatever for the Deb packager to the same as they are in the RPM packager which calls for much lower version numbers. Not needing a whole big total rewrite of Opera! Just making the Deb manifest match the RPM manifest because apparently those older versions are all that are actually required to make the update install and run on older distro versions. And it isn't going to break anything for people using the "latest and greatest, cutting edge, bleeding edge" version of their distro either, because it is my understanding if the manifest asks for only version 8 of a lib or whatever but your bleeding-edge version has version 800.3 it isn't going to matter -- gdebi or whatever is going to see the old version guy has 8 or above (and probably say "this guy needs to get with the times and upgrade his distro version ) and then install it, or it's going to say "wow, this guy other guy has version 800.3, that sure meets our requirements" and install it just fine for the bleeding-edge version guy too -- it installs for everyone.

l33t4opera

l33t4opera @Guest

@ridgerunner

The lib version requirements just have to be changed in the manifest or whatever for the Deb packager to the same as they are in the RPM

It's not that simple, it would require some time and effort from the developers to test it on several older distributions to check if there's no major issues, and it's safe to release it, besides that it rather not gonna happen because they are not supported already.
I will repeat it one more time, so for now you can simply unpack it from the package and use it if it works for you, or do the changes in the manifest as you please, or you can simply wait for some actions from the Opera's side.

And yes, I have read that post by filbo, and I think I understand it ;-)

A Former User @l33t4opera

@l33t4opera said in can not install, dependency unsolvable (not gtk>=3.0 or whatever):

@ridgerunner

The lib version requirements just have to be changed in the manifest or whatever for the Deb packager to the same as they are in the RPM

It's not that simple, it would require some time and effort from the developers to test it on several older distributions to check if there's no major issues, and it's safe to release it, besides that it rather not gonna happen because they are not supported already.
I will repeat it one more time, so for now you can simply unpack it from the package and use it if it works for you, or do the changes in the manifest as you please, or you can simply wait for some actions from the Opera's side.

And yes, I have read that post by filbo, and I think I understand it ;-)

And I am respectfully saying that I do think it is that simple Now l33t4opera, please don't take what I am going to post as confrontational or trying to get a 'flame-war' started. It is not meant so, and I am trying to stay as respectful as I possibly can here. But I think I need to confess a few things.

For the sake of full disclosure I believe that I should have disclosed a few things before answering any more posts that were going to get into a technical nature. Yes, I am a Linux newbie. No, I am not a computer newbie. No, I don't keep up to date on all of these things any more, I am old enough I no longer desire to keep on the bleeding edge of tech knowledge -- I just want to install my OS and programs and my daggone computer to work.

But, I got into computers enough decades ago I was using computers back when a lot of people who post here probably weren't even born - some of their mommies and daddies might not have even been a gleam in grandma and grandpa's eye let alone born yet either.

My first serious computer was a Commodore Colt, bought in 1989, with 64 kb (yes, kb not GB or TB) of system memory, no hard disk it ran on two 5&1/4 floppies, and it ran MS DOS 6.22 and I don't even think it would run (Don't remember if Bill and his posse over at Microsoft had even written Win 3.1 yet) MS Windows 3.1, the first version of the Windows GUI family.

If you want to count computers where you were just playing around, my first computer was acquired in 1981, a Timex Sinclair Z81 that everyone thought was the greatest thing since sliced bread because although like all the other computers at that time it used a cassette player as the hard drive, and your TV as the monitor -- it wasn't limited to whatever system memory they installed in it from the factory, it had these memory modules on them and you could plug them into each other (2 or 3 was the top limit?) and daisychain yourself double or triple the system memory as what came in the computer!!! (As Mr Spock would say, "Fascinating!") But that wasn't a serious computer undertaking, I just typed in some BASIC programs and saved them on cassettes and ran them. That was recommended to my dad by the IT guy at his factory as a good computer for beginners/kids to start out with -- he had built his own from scratch (with prodigious application of solder and the soldering gun), a Heathkit kit from Tandy/Radio Shack.

After I got the Colt in 89 and the many newer systems over the decades to follow, I picked up a, well, more than basic (BASIC, get it? hehe) knowledge of writing .bat files, programming/scripting, MS Windows guts ( Win 3.1 through Windows 7 at which point I switched to Linux because I found out that from Win 8 on, MS was going to be doing some pretty raw stuff with my personal data), etc.

Now the whole purpose of that is not to make myself sound all ' l33t ' and stuff. I am not, never was. But it is a little bit of a 'resume' to establish that I do know the difference between : 1. Oh crap, I gotta rewrite all the binaries and libraries for my program (where did I put my lucky rabbit's foot, my 4 leaf clover, my lucky favorite coding shirt I wear when I sit down at the keyboard and my 48-pack of Redbull cause I'm gonna be up 3 days and nights straight just getting started on this rewrite!) and 2. Oops, I had something set wrong in my compiler/interpreter/IDE/packager/whatever thingy , I went in and changed it and everything is ok now!

Now. Filbo (over in the comment on the blog post about the, at-that-time, latest version update of Opera {68.0.3618.5}) establishes pretty clearly this isn't anything to do with the binaries or anything itself, and also points out that even newer versions of Chrome install happily while that version of Opera (based off an earlier version of the Chrome code) refused to. That is about the time I started having problems with Opera updates not installing myself -- I just didn't bother with trying to fix it, just didn't upgrade. Then he quite clearly states the fix he used, which worked : Filbo "My system has libgbm1 10.1.3-0ubuntu0.6. I converted the RPM build of 68.0.3618.5 to DEB with alien, and the converted package only calls for 'libgbm1 (>= 8.1~0)', well within the range of my system." Then he asks the Opera Devs to "But earlier releases installed fine; this is caused by an unnecessary change in your build environment. Your RPM build environment says only 8.1~0 is required; please change the DEB packaging manifest to the same."

So. That takes care of (and establishes what the problem is with) the libgbm1 problem. DEB build environment is asking for much higher version numbers of libraries etc where RPM build environment is asking for much lower version numbers.

Now. kmod is having the same problem, but his is with the libgtk319 library. DEB build is asking for higher version numbers of the library than it really needs. In just a moment, I will get to how I know it is asking for much higher versions than needed -- in his step by step fix to the DEB manifest(?) (what he refers to as a DEBIAN control file) he only 'steps back' the version number of libgtk319 from libgtk-3-0(>=3.19.12) to libgtk-3-0(>=3,18.9). It works, and his fixed .deb file installs and runs fine.

OK. Now how that I know they Filbo and kmod have hit the nail right square on the head. I went through the exact same fix Filbo did on a Mint 17.3 install to fix the .deb file to fix the libgbm1 problem. Fixed it, did not get a dependency error message for it. But then I did get a dependency error for, wait for it -- libgtk319.

So. I followed kmod's step-by-step fix for libgtk library, (which was the same process I used to fix the libgbm1 problem) of changing the version numbers in the DEBIAN control (manifest?) file -- but where he stepped back from 3.19.12 to 3.18.9, Mint 17.3 (based on Ubuntu 14.04) uses version 3.10.8, quite a 'step-back'! Double-clicked on the opera-fixed .deb file (attempt 2) and it installed and is running fine - I now have Opera Version:70.0.3728.119 running happily, 'like a scalded dog' right now, rocking 9 tabs and all the sites working perfectly.

Conclusion. From this, we have to deduce that this is not a problem with the binaries, libraries, etc. So this is not going to be a marthon 48-pack of redbull and up days and nights combing through 1,000's of lines of Opera code, trying to fix the code to shut-up a few people on old distro versions class-of-situation. This is a take a few minutes (maybe hour or 2 at most?) and look at the DEB build environment and RPM build environment, find out why RPM only calls for much older versions and they work just fine while DEB calls for latest cutting edge versions and so people who have older distro versions which are still in LTS support until 2021.

l33t4opera, yes filbo did admit in that link I posted that he is running Linux Mint 17.3 in his comment post on the Opera Beta update blog (the same distro and version I used), and yes, that one is very old and out of support, so it would be understandable if the Opera Devs did not want to try to support that. But if you read the forum thread I linked to in my OP which has kmod's step-by-step solution to the problem with the DEB manifest (the DEBIAN control file?), you will see posts by other Opera users who are running distro LTS versions that are still in support, one of them is someone running Ubuntu 16.04 which is in LTS support until 2021 -- and those people do deserve to have the Devs trying to keep their product working for those in-support versions.

As I said, I did not make this very long post just to blow hot air and claim that I am some kind of Linux OS 'wizard' or 'computer/programming' Jedi Master. Just thought maybe I should establish the fact that while not particularly a Linux Guru (I consider myself a novice), I have been around computers for a long time, do know something about 'programming/scripting', and am at least not totally clueless about whether something is a 'problem-with-the-code' kinda thing that's going to be a days/weeks fix, or a 'oops, my settings weren't quite right in my compiler/IDE/packager' kinda thing that can probably be fixed in a few minutes or hour or so. So this post was not intended to be confrontational or argumentative Consider it my efforts to show that indeed filbo and kmod are right -- it isn't the code, it is something wrong with the DEB packager or whatever versus the RPM packager or whatever

Edit : An additional point which I just thought of that is a further indication that this is just something different/messed-up between the RPM packager and the DEB packager. I have not seen any complaints here in the forum from people running an RPM-based 'package/repo' manager Distro about their Opera is not updating and/or running. Just people on DEB-based 'package/repo' manager Distros. So another point that indicates this is just a problem of a difference between the RPM and DEB packager build environments. Just a little something I had noticed

kmod

kmod @Guest

@ridgerunner said in can not install, dependency unsolvable (not gtk>=3.0 or whatever):

I have an older distro version and I am getting a message like others talk about in this missing dependency post. It was locked, so could not ask about it in there, and probably better to do a new post on it, since it is a dependency for a different library (not even giving me a problem about gtk-3.0 or whatever they were having, maybe I have just not got far enough into the unsatisfiable hell I forsee I might be entering into trying to get Opera to run.

The message I get is that libgbm1(>=17.1.0~rc2) is the unsatisfiable dependency. Will the same fix that worked in the linked post (by user kmod ) I put in above work on this i.e. I change that control file for a lower version of that library? Or is this libgbm1 library something that is definitely required at that version level or above in order for Opera to run correctly?

the only way to find out is if you try run opera locally and see if it works by just extracting it and run https://forums.opera.com/topic/41676/solved-missing-dependency/18

It would be helpful if you tell us which distro you are running, For Debian based distros you can find out your library version by running this command in the terminal.

dpkg -l | grep libgdm1

I have 18.0.5 on the Ubuntu 16.04 machine and the OS is pretty old, if you don't meet the requirement libgbm1>=17.1.0~rc2 your OS has probably reached end of life, so your problem may be different from the other thread in that Opera might really require a newer version of libgdm1 to run. But then some Debian versions (old stable or something) run very old software so maybe it is still supported.

As said in my post on the other thread I have since switched to Vivaldi, which is a fork of Opera with a similar UI. It has already upgraded several times on my 16.04 machine since I visited this forum last time and haven't had any issue. It turned out opera on Linux has other unresolved issues besides upgrading on older distros, e.g it is a long standing problem that Opera cannot play videos on some websites like Netflix. See many threads on this forum. I tested in on a fully up to date Ubuntu 20.04 machine and the newest version of Opera. indeed Netflix doesn't work.There are hacks and workarounds and bug reports but it has never been fixed. On the other hand Vivaldi just works. Well really shouldn't be advertising for the competition here, so I will stop.

A Former User

It's not possible to install Opera 72.0.3815.148.Error message: missing dependency libxcb1 (>=1.12). Latest 71 version was fine. System Ubuntu 16.04. Can anyone confirm? Is there any solution for that? When you are going to fix that due to the fact that Ubuntu 16.04 hasn't reached EOL.

A Former User @Guest

@anab https://forums.opera.com/post/217255