Thanks. When my sister sent the printer to me – a HP Envy 4520 – as a Christmas Present several years ago,it was still a fairly new model at the time. I insisted on an HP because they work well with Linux. I had picked an older model I had researched but she sent me this one that probably cost more than double – mind you it is a very nice printer – it scans, prints, copies, does color print, does photos, etc., I just needed a BASIC PRINTER that PRINTED text. I chose the driver from HP’s driver list for Linux. Little did I know that I have to compile the driver from source 
. I suspect both the newness of the printer, and the multi-functionality of this printer required more than a basic driver. NEVER AGAIN!
I can take sources of open source software, create a spec-file and build RPM package, and then share both the src.rpm and binary package. You can look at the source code and the spec-file, but can you tell that the binary package is actually built from that src.rpm, or did I use different spec file and “additional patches” for actually building the binary package? Isn’t this a traditional way to inject trojans?
That does not mean that everybody out there is conjuring malicious packages.
1 Like
True, that goes a little back to what I said, the element of trust and there always is the risk. I personally couldn’t tell from the binary package as such. I’m sure someone could most likely reverse-engineer it to find out. As with everything there are trusted sources for obtaining packages, and those that either have less trust or none.
Anyway, we best get back on-topic for the OP 
Indeed. Package management is awesome.
- Package can list things that it depends on and provides. No need for trial and error “What else do I need?”
- The metadata allows also clean “remove” and “update” actions. This is more coherent than ‘uninstall’ rule in Makefile.
There can still be conflicts between unrelated repositories* and it is not always clear which packages the build environment had, i.e. which/why dependencies were marked into a package.
*Example: RPMFusion provides VLC. Good repo, decent application. The VLC requires a feature “X”. Another package in RPMFusion does provide X. That package cannot co-exist with NVidia driver package from ELRepo repo. The ELRepo’s NVidia package does provide X too.
If I install VLC first, then it pulls the other package from RPMFusion and I can’t install NVidia’s driver.
If I install NVidia’s driver from ELRepo first, then VLC installs cleanly.
If I install NVidia and VLC simultaneously … gee, haven’t tried that, so can’t tell what happens.
Oh, RPMFusion has a NVidia driver too, and so does NVidia’s own repository. The devil is in the details.
Oh please, continue. It seems kinda off topic, but it really isn’t. It very much fits in with what I was asking.
[root@xxx ~]# dnf search teamviewer_15.29.4.x86_64.rpm
Last metadata expiration check: 2:01:34 ago on Sat 07 May 2022 08:12:11 AM PDT.
No matches found.
[root@xxx ~]# dnf search teamviewer
Last metadata expiration check: 2:01:44 ago on Sat 07 May 2022 08:12:11 AM PDT.
No matches found.
So, I implicitly searched for version with .rpm and then, just generally.
When I attempted to install originally, I went to the Teamviewer site and they have an rpm that claims to work with RHEL/CentOS/Fedora (should work with Rocky, right?). I downloaded that and attempted to install, and that is where I ran into the dependency problem.
[root@xxx TeamViewer]# rpm -ivh teamviewer_15.29.4.x86_64.rpm
warning: teamviewer_15.29.4.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 0c1289c0: NOKEY
error: Failed dependencies:
libminizip.so.1()(64bit) is needed by teamviewer-15.29.4-0.x86_64
I listed in a previous post, repos that I have installed.
try this:
dnf install teamviewer_15.29.4.x86_64.rpm
that command will resolve the dependencies too, rpm on it’s own will not.
[root@xxx /]# dnf install teamviewer_15.29.4.x86_64.rpm
Last metadata expiration check: 2:35:19 ago on Sat 07 May 2022 08:12:11 AM PDT.
Can not load RPM file: teamviewer_15.29.4.x86_64.rpm.
Could not open: teamviewer_15.29.4.x86_64.rpm
That didn’t work.
Maybe it’s not downloaded properly, as that should install. It cannot load it for some reason, which is weird.
Were you in directory “TeamViewer” that contains the file “teamviewer_15.29.4.x86_64.rpm” when you ran ‘rpm’, but in directory “/” when you ran ‘dnf’?
dnf install ./teamviewer_15.29.4.x86_64.rpm
You make a really good point. I was thinking about this when someone posted a binary rpm in another thread. I’d say most people would not know.
Yes I was in root when I ran dnf install and in the directory where I had downloaded the rpm, when I ran rpm…
If you refer to file as “teamviewer_15.29.4.x86_64.rpm” or “./teamviewer_15.29.4.x86_64.rpm”, then you have to be in the directory, where the file is.
If you want to run the command elsewhere, then the filename requires a path component.
For example, if the file is in directory “/home/gary910/Downloads” and you are in directory “/home/gary910/Documents”, then
absolute: “/home/gary910/Downloads/teamviewer_15.29.4.x86_64.rpm”
or
relative to your location: “../Downloads/teamviewer_15.29.4.x86_64.rpm”
1 Like
Yes, I understand that. I understand relative paths.
My issue has to do with dependencies. I have posted what I have done, please review.
The problem isn’t just with TeamViewer, it is with other apps as well. Notice the OP, it is with Gramps as well. I appreciate the input from all, but I feel like I am not being understood. Maybe I am not communicating the issue correctly, I don’t know.
A note about dnf and rpm: the dnf creates a log of transactions that one can see with dnf history. One can search the log, and also do operations like “undo” and “redo”. That is, when you install one package where the transaction installs dependencies, the yum history undo can conveniently uninstall all those packages.
The rpm does not write to that log. Therefore, one should not use rpm for anything but reading data about installed packages. All installs/removals via dnf. (The ‘yum’ is symlink to ‘dnf’, so yum is synonym for dnf.)
More importanly, rpm does not automatically resolve dependencies. A ‘rpm -i X Y Z’ installs only the packages X, Y, and Z, while ‘dnf install X Y Z’ installs also packages that the X, Y, and Z depend on.
Some guides – and worse: some scripts – still use ‘rpm’, but one really should replace those instructions with ‘dnf’.
So, now we get to the point that you have a package W, either as file or in third-party repository, and ‘dnf install W’ says that it can’t resolve all required dependencies. The issue is that the package W has been built in environment that has some packages that are neither in base repositories nor in that third-party repository where the package is. In case of ‘teamviewer’ the required package is in EPEL. Some packages in EPEL depend on packages that are in repository ‘powertools’. The powertools is Rocky’s own repository, but not enabled by default.
The thing to do when dnf reports features/packages that it can’t find from enabled repositories is to websearch that feature. (I usually add “rpm” as another keyword.) This usually results in list of distros/repos that have such package.
I don’t know “Gramps”, nor what it requires.
1 Like
Here you go:
[root@rocky ~]# dnf list gramps
Last metadata expiration check: 0:00:52 ago on Sun 08 May 2022 11:30:49 CEST.
Available Packages
gramps.noarch 5.1.2-1.el8 epel
since it’s available in the epel repository, do this:
dnf install epel-release
dnf install gramps
As for teamviewer:
[root@rocky ~]# pwd
/root
you can see I am in /root directory. Now I download it using wget:
[root@rocky ~]# wget https://download.teamviewer.com/download/linux/teamviewer.x86_64.rpm
--2022-05-08 11:33:10-- https://download.teamviewer.com/download/linux/teamviewer.x86_64.rpm
Resolving download.teamviewer.com (download.teamviewer.com)... 104.16.62.16, 104.16.63.16, 2606:4700::6810:3e10, ...
Connecting to download.teamviewer.com (download.teamviewer.com)|104.16.62.16|:443... connected.
HTTP request sent, awaiting response... 302 Found
Cookie coming from download.teamviewer.com attempted to set domain to downloadprovider.teamviewer.com
Cookie coming from download.teamviewer.com attempted to set domain to downloadprovider.teamviewer.com
Location: https://dl.teamviewer.com/download/linux/version_15x/teamviewer_15.29.4.x86_64.rpm [following]
--2022-05-08 11:33:10-- https://dl.teamviewer.com/download/linux/version_15x/teamviewer_15.29.4.x86_64.rpm
Resolving dl.teamviewer.com (dl.teamviewer.com)... 104.16.62.16, 104.16.63.16, 2606:4700::6810:3f10, ...
Connecting to dl.teamviewer.com (dl.teamviewer.com)|104.16.62.16|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 67205437 (64M) [application/x-redhat-package-manager]
Saving to: ‘teamviewer.x86_64.rpm’
teamviewer.x86_64.rpm 100%[===========================================================>] 64.09M 28.9MB/s in 2.2s
2022-05-08 11:33:13 (28.9 MB/s) - ‘teamviewer.x86_64.rpm’ saved [67205437/67205437]
after it’s downloaded:
[root@rocky ~]# dnf install teamviewer.x86_64.rpm
Last metadata expiration check: 0:02:28 ago on Sun 08 May 2022 11:30:49 CEST.
Dependencies resolved.
======================================================================================================================================
Package Architecture Version Repository Size
======================================================================================================================================
Installing:
teamviewer x86_64 15.29.4-0 @commandline 64 M
Installing dependencies:
desktop-file-utils x86_64 0.23-8.el8 appstream 79 k
libXScrnSaver x86_64 1.2.3-1.el8 appstream 30 k
libdrm x86_64 2.4.106-2.el8 appstream 166 k
libglvnd x86_64 1:1.3.2-1.el8 appstream 126 k
libglvnd-glx x86_64 1:1.3.2-1.el8 appstream 136 k
libpciaccess x86_64 0.14-1.el8 baseos 31 k
libxkbcommon-x11 x86_64 0.9.1-1.el8 appstream 24 k
libxshmfence x86_64 1.3-2.el8 appstream 12 k
mesa-libGL x86_64 21.1.5-1.el8.0 appstream 183 k
mesa-libglapi x86_64 21.1.5-1.el8.0 appstream 64 k
minizip1.2 x86_64 1.2.11-24.el8 epel 32 k
nspr x86_64 4.32.0-1.el8_4 appstream 141 k
nss x86_64 3.67.0-7.el8_5 appstream 740 k
nss-softokn x86_64 3.67.0-7.el8_5 appstream 486 k
nss-softokn-freebl x86_64 3.67.0-7.el8_5 appstream 394 k
nss-sysinit x86_64 3.67.0-7.el8_5 appstream 72 k
nss-util x86_64 3.67.0-7.el8_5 appstream 136 k
xcb-util x86_64 0.4.0-10.el8 appstream 21 k
xcb-util-image x86_64 0.4.0-9.el8 appstream 20 k
xcb-util-keysyms x86_64 0.4.0-7.el8 appstream 15 k
xcb-util-renderutil x86_64 0.3.9-10.el8 appstream 18 k
xcb-util-wm x86_64 0.4.1-12.el8 appstream 31 k
xdg-utils noarch 1.1.2-5.el8 appstream 83 k
Transaction Summary
======================================================================================================================================
Install 24 Packages
Total size: 67 M
Total download size: 3.0 M
Installed size: 258 M
Is this ok [y/N]: ^COperation aborted.
obviously I aborted the transaction above, but otherwise it would have installed. Since my Rocky is a minimal install, then the dependency list may be shorter than mine. Either way, as was mentioned before, providing you don’t download it and change directories, then the dnf command will work to install it. Follow my example above exactly, and you cannot go wrong.
Thank you, the wget was the trick for Teamviewer.
As far as Gramps…
[root@xxx /]# dnf install epel-release
Last metadata expiration check: 2:05:25 ago on Sun 08 May 2022 07:50:53 AM PDT.
Package epel-release-8-15.el8.noarch is already installed.
Dependencies resolved.
Nothing to do.
Complete!
[root@xxx /]# dnf install gramps
Last metadata expiration check: 2:06:03 ago on Sun 08 May 2022 07:50:53 AM PDT.
Error:
Problem: conflicting requests
- nothing provides osm-gps-map-gobject needed by gramps-5.1.2-1.el8.noarch
- nothing provides python3-pyicu needed by gramps-5.1.2-1.el8.noarch
(try to add ‘–skip-broken’ to skip uninstallable packages or ‘–nobest’ to use not only best candidate packages)
Well, after a google for those dependencies, they existed in EPEL7, but not in EPEL8 it seems. Found this too:
https://bugzilla.redhat.com/show_bug.cgi?id=1963722
so I guess you’ll need to wait until that has been resolved by the maintainers. Alternatively, you could try doing what the output said using --skip-broken or --nobest:
dnf install gramps --skip-broken
or:
dnf install gramps --nobest
if that doesn’t work, I guess you’ll just have to give up on it for the time being. Also, read back over this post, and look at some of the dnf commands we have been using - this will help you learn how to find packages that are available, but may not have the repository for them enabled. An example below:
[root@rocky ~]# dnf search osm-gps-map-gobject
Last metadata expiration check: 7:33:27 ago on Sun 08 May 2022 11:30:49 CEST.
No matches found.
[root@rocky ~]# dnf search python3-pyicu
Last metadata expiration check: 7:33:41 ago on Sun 08 May 2022 11:30:49 CEST.
No matches found.
of course that didn’t find anything. But you can see examples of how you can use those commands and search and find packages to see if they exist or not. That way you are not relying on us having to search for you, as you will be able to do it for yourself. A working example was for gramps:
[root@rocky ~]# dnf list gramps
Last metadata expiration check: 7:43:00 ago on Sun 08 May 2022 11:30:49 CEST.
Available Packages
gramps.noarch 5.1.2-1.el8 epel
using list instead of search, but either way, you can see that it is in the epel repository. Now using dnf search and dnf info to find the package that might not have the repository enabled for it:
[root@rocky ~]# dnf search gramps
Last metadata expiration check: 7:43:39 ago on Sun 08 May 2022 11:30:49 CEST.
=========================================== Name Exactly Matched: gramps ============================================
gramps.noarch : Genealogical Research and Analysis Management Programming System
[root@rocky ~]# dnf info gramps
Last metadata expiration check: 7:43:44 ago on Sun 08 May 2022 11:30:49 CEST.
Available Packages
Name : gramps
Version : 5.1.2
Release : 1.el8
Architecture : noarch
Size : 9.6 M
Source : gramps-5.1.2-1.el8.src.rpm
Repository : epel
Summary : Genealogical Research and Analysis Management Programming System
URL : https://gramps-project.org/
License : GPLv2+
Description : gramps (Genealogical Research and Analysis Management Programming
: System) is a GNOME based genealogy program supporting a Python
: based plugin system.
the info command also showing that it belongs to epel. The list command mostly will work only when the repo is enabled, whereas search will work even if epel is disabled.
For now I don’t suggest you think about compiling gramps, as compiling is a far lot more effort than simple dnf commands. Hopefully epel maintainers will fix that issue soon.
Hi,
I noticed gramps is available as a flatpak package (also compatible with rocky, and should include all dependencies)
You could try this.
https://www.gramps-project.org/wiki/index.php/Download#Flathub
flatpak is a way of using containerized applications
Works very well on rocky, on my desktop I use it for all applications that I don’t trust to respect my privacy…microsoft teams, spotify, slack)
it will also work very well on a rocky linux server
it fakes root so the app thinks it is installed as root even though its running using an unprivileged user account, so only access to stuff that is needed according to you and not them 
also really prevents the automatic starting of apps unless you explicitly put them in your autostart. (no more disabling required after each update)
here are the rhel flatpak installation instructions (identical for rocky)
https://flatpak.org/setup/Red%20Hat%20Enterprise%20Linux
cheers
p.s. teamviewer is definitely one off those apps that I don’t trust to respect my privacy
sadly it does not come in a flatpak package
an alternative might be anydesk also corporate, but it comes as a flatpak package, which isolates it from all the sensitive bits