I have posted here that I am a new “Full-Time” RL user (and Linux).
I am in the process of retiring my old W7 machine. Before I switched over, I did a lot of research and thought of how I was going to do “X” and “Y”. I had 95% worked out, and the remaining 5% felt like nothing. (Well, so I thought.) I researched the applications that I used and thought I had it pretty much covered. I love a challenge so I am not giving up. I just feel like I need some help.
I use Gramps. There is a package in one of the repositories, but there are some dependencies missing…“Okay, not critical right now, I will get it worked out.” I need TeamViewer to support a couple of people. So I go to the TeamViewer website and there is a RHEL/Centos/Fedora rpm to install. “Hey, great, I am all good.” Wrong, again, missing some dependencies. I have heard about “Dependency Hell”, but didn’t think I would experience it. (At least very much.) I understand there are some growing pains, but ugghh. As and IT person, I know better than to give up.
Can anyone point me in the right direction. I do IT support (Windows) so I know how this works. I am not asking anyone to “Do it for me”, I just need to know which direction to go.
I’m not that experienced in these matters (still considering myself as a newbie after 10 years of Linux) but what exactly does dnf/yum say about these missing dependencies upon installation? Could it be that it can’t find packages that contain the missing files because it’s “software sources” list is missing e.g. rpmfusion, epel, something… or did you already check that?
As @schroedingersdog said, also check powertools repo since this isn’t enabled by default also which could be a reason for it.
Please post the list of dependencies that it had issues with, as we can then help you identify which repository that they would be available in. First I would enable powertools and also install the epel repository as a basic setup and go from there. If that doesn’t resolve it, post back with the list of dependencies what still cannot be installed.
You can also use:
dnf search <packagename>
which can help see if the package is available, and also to which repository it belongs. And use:
to see what repos you have got enabled. You can add the --all parameter to the repolist command to see all the repos that your system sees and can enable.
I have installed TeamViewer on AlmaLinux. The only issue was that I despise TeawViewer. (Alma and Rocky are practically identical; both should have same dependency issues.)
As support person you do know that “some dependencies” does not tell what actually went wrong. Show what you did and what you did got. As a by-product of solution to the specific issue you might learn the general approach that we use.
that’s great! Now, given the fact you have TeamViewer up and ready on Alma, would you mind sharing your repolist with @Gary910 so he could have a first look for whether relevant repositories are missing at his side?
Wow, that’s an awesome bunch of useful information, thanks a lot @jlehtone !
That should provide @Gary910 with all the necessary bits to solve their install trouble.
On a side-note:
I wonder if there ain’t some kind of RockyLinux FAQ site for such hiccups, like a list of “apps known to require some fiddling”. Maybe the “gems” thing. Will check, once @Gary910 confirms that their issues were solved by your information.
Not really, because it’s supposed to be an enterprise o/s, so nothing should need any “fiddling”, everything should be planned based on the official repos supported by RHEL, which does not include ‘epel’. Of course you can install things that are not supported, but they might not work. The packages in the official repos should not have any failed dependencies, although it can happen e.g. with streams and modules.
repo id repo name
appstream Rocky Linux 8 - AppStream
baseos Rocky Linux 8 - BaseOS
epel Extra Packages for Enterprise Linux 8 - x86_64
epel-modular Extra Packages for Enterprise Linux Modular 8 - x86_64
extras Rocky Linux 8 - Extras
powertools Rocky Linux 8 - PowerTools
rpmfusion-free-updates RPM Fusion for EL 8 - Free - Updates
rpmfusion-nonfree-updates RPM Fusion for EL 8 - Nonfree - Updates
dnf install teamviewer_15.24.5.x86_64
Last metadata expiration check: 0:32:14 ago on Wed 04 May 2022 06:31:58 PM PDT.
No match for argument: teamviewer_15.24.5.x86_64
Error: Unable to find a match: teamviewer_15.24.5.x86_64
No go for me. As you can see I have epel, powertools installed.
The command dnf install packagespec looks at the packagespec. The packagespec is either name of package or feature (optionally with specific version) that is looked from enabled repositories or it is a name of a file (can be URL too).
I had used teamviewer_15.24.5.x86_64.rpm, which was the name of the file that I had downloaded from TeamViewer’s site. The teamviewer_15.24.5.x86_64 does not look like name of a file – RPM files usually have extension .rpm. Besides, the version is different, if you do download now.
Just to follow up on what @jlehtone said. If you download an RPM file, you must provide the full name when attempting to install it. So let’s assume that the file you download is teamviewer-15.29.4-0.x86_64.rpm, then the command would be:
dnf install teamviewer-15.29.4-0.x86_64.rpm
obviously assuming that you are in the same directory as where you downloaded the rpm. That will resolve the dependencies. I always used to use the rpm command but had to manually resolve the dependencies myself first, so using dnf is far easier. Yum would also do the same in prior versions.
If you do not provide the full filename, then it is attempting to install it from the repositories configured on your system - and this doesn’t work because teamviewer is not in the repositories.
“I have heard about “Dependency Hell”, but didn’t think I would experience it. (At least very much.”
Nah. Today it is almost automatic. When Linux was still young and everything was installed by rpm files it could take 2-3 days to get all the dependencies – and in the right order! – to install one program that required a boatload of dependencies. I for one am very glad those days are mostly in the rear view mirror. There are some programs that still do not play nice today.
The thing that still sends shivers down my spine are building anything from source. My buddy is a whiz at doing things like that, but not yours truly. I’ve done it 3 times on my own, and that was 3 times too many. Once was when I installed my HP Printer, and all I thought I needed to do was install a driver… In my case I had to do it from source and took some 2 hrs. I am seriously considering letting leopard be my print server after I have ocelot solidly up and running, rather than trying to migrate the printer to ocelot.
TLDR: Consider using RL as your main OS with Windows as a VM - essentially a browser on your windows apps.
I feel your pain - I’m moving from Windows to Linux (almost there) and thought I had it figured out at the start only to find I had only seen the tip of the iceberg…
Huge improvements in recent years though, particularly with virtualisation (kvm/qemu) makes things MUCH easier.
Few turds in the ointment :
Supporting Windows users ( IT support for you, testing cross-platform software on Windows for me)
Desktop Excel : there is no decent replacement for Desktop Excel
Some entertainment services/applications don’t work / aren’t available on Linux
WINE - I couldn’t get it to work , only supports specific versions of windows applications and is redundant given kvm/qemu.
“Just build it” usually means “Just fix build / dependency errors for a few hours”… or try to and give up.
I’m transitioning to a system where
I run RL/KDE as my main OS
I run a Windows VM on my main RL machine and switch to the VM when I need Excel or other Windows stuff. (as opposed all the WINE malarky) - files shared between OSes via samba.
I run Fedora Server as a VM for some sw not in RL repos eg Bugzilla. (2 threads 4MB) but as its there I throw a copy of MediaWiki and some other server apps on there too.
I’m left with 6 threads and 20GB for RL which is fine to date.
Thats all on one 7yr old Dell Precision, though I’ll move the server stuff off eventually.
Now, I have my Win VM on a different physical drive and it gets 4 threads and 8GB Ram so effectively I just have 2 PCs running at the same time on the same box where I can cut/paste between them.
I was initially going to use Win 7 for the VM - for all the reasons you would want 7 over 10+ but figured I have to run 10 anyway as its the world we live in.
There are basic gotchas all along the way eg.
Don’t pause VMs or you’ll need to resync the time when you unpause.
Don’t use the default storage options on RHEL/RL installs - it leaves no spare space for LVM snapshots.
NVidia not (really) supported.
Multiple monitors in the right position ? ( Wayland or Xorg ?)
Lots of other HW not supported - figuring out what IS supported ? (lsmod, modinfo, look in /lib/modules/$(uname -r)/kernel/drivers/)
You just pick these up as you go along … and fall over them.
Some advantages are
I can leave Windows disconnected from the internet most of the time and turn off AV etc.
I don’t have my working machine suddenly become unusable at a critical moment (moving odds!) due to Windows house keeping / disk access at 100% or go into a 5 hr update and come out bricked.
I can use backed qcow2 files to do updates and toss em if they don’t work / I want to leave the issue for later.
I’m learning a system I have control over and will be in a much better place in the future.
No Windows licensing restrictions / costs on servers.
Not tied to ever deteriorating Microsoft software.
Worth the effort ? depends on your specific situation. For me yes, for a lot of people, including most small businesses and the general public I would say probably not.
I am right there. I am running a Windows 10 VM for stuff that won’t run on Linux. I have been running Linux VMs for over 10 years trying to learn. It is just recently, I decided to jump in the deep side of the pool and fully commit. For the most part, so far, it is a great experience. The title of the topic isn’t “A lot of frustration” it is “A little frustration”. @jlehtone and @iwalker . Thanks, yes, I should use the file extension. I will try that, and report back if that works.
Thank you all for the comments. That there have been so many comments shows the beauty of Linux and the community. This makes me even happier I have become a full-time Linux user.
Downloading rpm’s from Teamviewer isn’t random. There are plenty of repositories being managed by various organisations and that is not risky. Elasticsearch for one, MongoDB for another, MariaDB also have their own repositories. There is a difference between those types of repositories, and some random rpm made by an individual that nobody knows.
Teamviewer is not opensource. The rpm doesn’t have to be opensource, it is a package that is generated that allows you to cleanly install and uninstall it - which cannot always be said about manually compiling something (albeit make uninstall should do that providing it has been implemented in the appropriate source). Teamviewer have their own repository which is then created as a repo file under /etc/yum.repos.d/teamviewer.repo and therefore any updates after initially downloading the rpm from Teamviewer are pulled in using dnf update.
Now whether you like Teamviewer or not is a different matter. For free use yes it’s limited and sometimes ends up being blocked incorrectly when they apparently detect business use. And a license is certainly expensive if you don’t use it regularly enough. But that is a different issue.
I’ve used NX-NoMachine for remote connections to my Linux machines, and it’s pretty good. Far easier than attempting XRDP or desktops that have 3D enabled since the RDP doesn’t play nicely then. In those cases, it was a simple desktop using LXDE for getting around that (Gnome for example).
But isn’t it the case that MongoDB and MariaDB are both open source and so you could use (or inspect) the source rpm, whereas ‘teamviewer’ is not. In terms of security, anything that’s not open source can be dangerous, because as soon as you install the rpm as root, it can do what ever it wants including installing a back door to your server. This is the big reason to choose free and open source. The other being product cost and licensing, but I don’t see how any application or o/s that’s not open source could ever be audited for security?
That’s something different entirely. Whether you prefer to use open-source or proprietary software isn’t the point here. That’s a personal choice that anyone can make. Some may not wish to use proprietary and that is fine. Some may want to.
Just because Teamviewer provides a proprietary application and provides it by a repository to make it easy to install and update, doesn’t mean that it’s a security risk any more than any other package - open source packages also suffer from security issues and some have even been hidden away for years before they came to light. Sure, some are easier to inspect than others. Some companies even have their products audited by third-parties to help alleviate the issue that the normal person can’t audit or check it himself.