Djvu instalation failed dependencies

Hello Friends!
I have Rocky 8.4, and have an interest in reading djvu files. To that end, I found djviewer

I see that the djvulibre website
lists djview4 ( DjVuLibre: Open Source DjVu library and viewer ) as an improved viewer
Further, for Fedora/RHEL we have a binary package - djview4-4.12-3.fc35 | Build Info | koji

When installing this, I ran into dependencies issue. The following are missing in my case
[root@galileo Software]# rpm -Uhv djview4-4.12-3.fc35.x86_64.rpm
error: Failed dependencies:
glibc >= 2.33.9000-43.fc35 is needed by djview4-4.12-3.fc35.x86_64 is needed by djview4-4.12-3.fc35.x86_64 is needed by djview4-4.12-3.fc35.x86_64 is needed by djview4-4.12-3.fc35.x86_64 is needed by djview4-4.12-3.fc35.x86_64

I have checked my glibc version
[root@galileo Software]# rpm -q glibc

My question is: Can I update glibc and install above dependencies and continue to run Rocky without any clashes in dependencies etc.? I have seen some webpages indicating updating glibc should be OK since versions are supposed to be backward compatible, but I thought I will ask here anyway.


No. Practically everything in the distro depends on the glibc (and some other components).
One does not simply replace the base components, ever.

Get the source RPM of that “djview” and build the binary packages for Rocky.
(mock is commonly used for (re)building packages.)

PS. Do not use rpm for installing any packages. The dnf install djview4-4.12-3.fc35.x86_64.rpm works as well (or better – it can pull dependencies and it records the transaction to dnf history).

Thank you, this is a valuable lesson learnt for me - thankfully I thought of asking before just updating glibc.

Out of the two [building from source vs using dnf install] which one do you suggest we prefer in general.

I guess it would be building from sources as it would involve using the latest version as desired by the developer?


If package has been built for the platform (here Rocky), then that (dnf install) should be the first option.
If package is from unknown source and would replace/remove already installed system packages, then be sceptic.

If a package can be built for the platform, then that is an option, because you can dnf install/upgrade/remove.
Build as regular user, never as root.

If the only option is “build from sources”, then don’t put files among system files (no default make install). Put the result in distinct directory (for example, under your homedir).

Do note that Rocky is based on RHEL and RHEL contains backported features. That is, at some point Red Hat creates a branch of some application for RHEL. The formal version string does not change, but after a while the branch in RHEL differs from its origin. For example, in around 2013 Red Hat took Linux kernel 3.10 and based kernel it RHEL 7 on that. It is still in use, still called “3.10”, but different from what upstream 3.10 was. Yes, it isn’t like upstream 5.15, but it for sure has a feature that upstream introduced in 3.13.

Hello again, @jlehtone
Merry Christmas!
I am sorry I keep bothering you…
I tried the command you suggested - namely installing using dnf install …
this is the result

[root@galileo sources]# dnf install djview4-4.12-3.fc35.x86_64.rpm
Display all 16732 possibilities? (y or n)

I gave no (n) as the response here, the system immediately came out waiting for me to enter at the prompt
I gave same command again… and this followed.
[root@galileo sources]# dnf install djview4-4.12-3.fc35.x86_64.rpm
Last metadata expiration check: 12:08:12 ago on Friday 24 December 2021 01:31:57 AM IST.
Problem: conflicting requests

nothing provides glibc >= 2.33.9000-43.fc35 needed by djview4-4.12-3.fc35.x86_64
nothing provides needed by djview4-4.12-3.fc35.x86_64
nothing provides needed by djview4-4.12-3.fc35.x86_64
nothing provides needed by djview4-4.12-3.fc35.x86_64
(try to add ‘–skip-broken’ to skip uninstallable packages or ‘–nobest’ to use not only best candidate packages)

Can you explain what is happening? At this point, I skipped djview4-4 and looked online again for a djvu reader
I found Okular.

Says out there loud and clear… it supports djvu format… so I went ahead and installed using
[root@galileo sources]# dnf install okular-21.08.3-1.el8.x86_64
Last metadata expiration check: 12:22:53 ago on Friday 24 December 2021 01:31:57 AM IST.
Dependencies resolved.

It installed Okular, and I tried opening a djvu file, only to get a message -

“Could not open file:///home/user01/Documents/ERT.djvu.
Can not find a plugin which is able to handle the document being passed.”

I don’t understand, if the website shows the djvu logo, why does it now need plugins?

I am at my wits’ end. Can you please point me to a solution to help me read my djvu files?


That kind of message usually comes from bash command completion, not from dnf.

A binary package built for fc35 depends on libraries present on fc35. One should take the source package ( ) and rebuild the binary package for Rocky. That either sets package to depend on what Rocky has, or build fails.

“Plugin” hints of optional feature. Those could be in separate packages. Alas, EPEL 8 does not have “okular-djvu” or similar. (Neither does RHEL 7.) For some reason that plugin has not been built on these platforms.

I did look with:

dnf list \*okular\*
dnf list \*djvu\*
dnf provides \*djvu\*
dnf provides */\*djvu\*

and while some packages in ‘epel’ have filenames containing “djvu”, there is no executable/plugin/library in that set that handles djvu.

I think your path of least resistance would be to install the okular or evince flatpak. It looks like it will read djvu files, plus it will be isolated from your main system so you won’t have to worry about library incompatibilities or building from source.

setup the flathub repository: Flatpak—the future of application distribution

then install okular: Flathub—An app store and build service for Linux

or install evince: Flathub—An app store and build service for Linux

thanks for dropping by and offering to help.
I do recall installing either this or snap in the last iteration of my computer and it had been probably too heavy - i.e. too much disk space. I am sorry, my memory fails me.
What I do recall is that uninstalling it was not possible for me, at least with the limited understanding I have of Linux.

My questions:

  1. Can I install flatpak like so: Install Flatpak on AlmaLinux or Rocky 8 - Linux Shout
  2. How much space do I need on my /home or /usr wherever this flatpak is installed.
  3. Happily, I note that the link above says I can uninstall flatpak- Can I do the following:
    [A]. install Okular/Evince via flatpak and then uninstall flatpak,
    [B] After uninstalling flatpak continue to run evince?
  1. You can install it according to that guide
  2. I’m not sure how much space it will be. probably a few 100 MBs at most. It will be installed in your home directory by default.
  3. Flatpak is required to run the flatpak applications. If you uninstall it then you will not be able to run the Okular or Evince flatpak.

It is possible to completely remove everything you install with flatpak. There is no risk. I would say just give it a try.

Thanks @tkuraku
I will try flatpak method of evince

@jlehtone, I am unaware how to rebuild the binary package for rocky, but I still appreciate your guidance all along.

For my own and others benefit, I request you to please show/share this method of build/rebuild the binary package for Rocky. I have checked on this forum, but could not locate a discussion on this (basic?) step.
Considering I have build from sources for R-Studio, I will appreciate (as always) your guidance on how to do this for Rocky

@tkuraku @jlehtone
I am seeing that evince is available in centos packages, indeed when I type dnf install evince, I get the option of evince-devel-3.28.4-14.el8.x86_64

Do you suggest I use this? I suppose this is from centos EL8 repository.
there is also

The evince package available from the EL8 repositories doesn’t have the djvu libraries, as those aren’t shipped with EL8 as you have found. It won’t open the djvu files. The flatpak will include those libraries and can open and view the djvu files. Evince is installed by default with the server with GUI install, so you likely already have it installed and if you install the flatpak there will be two version of evince installed.

Try the flatpak.

Thank you for clarification. I tried, and installed flatpak and evince via flatpak. My djvu file can now be accessed via the flatpak evince.
Apparently, there was some other evince also - which did not run the djvu file - as you have pointed out from your last message.

As per the howtoshout link above, I was to update dnf first using the below command…
sudo dnf update
I did so, and followed the rest.
It did update my Linux to Rocky 8.5
This was not my intention - although I am not sure what to make of the updated Rocky 8.5. Typically, I stay one version behind the latest stable, just to keep away from anything that may hold up my work/usage.

For anyone who tries using evince via flatpak,
You will probably install flatpak - using root.
You will also search and install evince on flatpak - using root.
you will fire up evince via flatpak using (in my case) flatpak run org.gnome.Evince (again in root)
You will find that evince opens up and allows you to open a valid djvu file.

When you exit root and come to a regular user mode, and type flatpak run org.gnome.Evince, you will get an error: Unable to allocate instance id

Do not worry, you only have to reboot your machine and you can then run flatpak run org.gnome.Evince as a regular user.

Best regards,


You should perform an sudo dnf update regularly or you will not get necessary security updates and your system will have security vulnerabilities. Staying a point release behind is not a good idea.

Thanks, I will remember to do dnf update regularly.


I’m not an expert on the topic either. I’ve seen references to ‘mock’. It it possible to install ‘mock’ from EPEL.

Then, one does run mock as regular user. Mock creates chroot/container environment into which it installs packages required for a build and then builds. However, running:

$ mock --rebuild

fails, because it can’t install djvulibre-devel.

Rebuilding djvulibre-devel from source (from fc35 and even from fc32) fails, because the build uses feature of inkscape that is not yet in Rocky’s version. The version of djvulibre in fc31 builds on Rocky.

I did not dig into documentation of mock enough to figure out how to inject the custom-built djvulibre-{libs,devel} into the chroot, where mock would build djview4.

thank you @jlehtone for the headsup on mock.