Bug 1646701 - nothing provides /bin/basename needed by AdobeReader_enu-9.5.5-1.i486
Summary: nothing provides /bin/basename needed by AdobeReader_enu-9.5.5-1.i486
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: 29
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2018-11-05 21:08 UTC by Hin-Tak Leung
Modified: 2023-04-12 07:06 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1646699
Last Closed: 2018-11-05 22:03:38 UTC
Type: Bug

Attachments (Terms of Use)

Description Hin-Tak Leung 2018-11-05 21:08:15 UTC
coreutils-8.29-7.fc28.x86_64 provides /bin/basename, coreutils-8.30-5.fc29.x86_64 does not.


+++ This bug was initially created as a clone of Bug #1646699 +++

Description of problem:
Ths last of the Adobe acrobat reader requires libidn.so.11

  - nothing provides libidn.so.11 needed by AdobeReader_enu-9.5.5-1.i486
  - nothing provides /bin/basename needed by AdobeReader_enu-9.5.5-1.i486

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Try to install adobe acrobat reader...

Actual results:
libidn on fedora 29 provides libidn.so.12

Expected results:
compat-libidn provides the older version?

Additional info:
The actual experience was that Adobe Acrobat Reader was blocking the libidn upgrade from fc28... and '--best --allow-erasing' caused it to be uninstalled.

Comment 1 Kamil Dudka 2018-11-05 22:03:38 UTC
The software is apparently not built for the Operating System you are using.  It needs to be fixed to require `coreutils` instead of `/bin/basename` and rebuilt against update libidn* packages.

Comment 2 Freddy Jensen 2020-09-08 20:42:02 UTC

I have posted a fix for this problem.

Please see:


1) Go into the folder: Acrobat/Acroread/Linux-Installer/2020-09-08-Version-1.0.0

2) Copy the two files: acroread.tar and readme.txt

3) Follow the instructions in readme.txt

Freddy Jensen

Comment 3 Kamil Dudka 2020-09-09 06:23:47 UTC
Freddy, does your solution rely on any of these provides?


They were introduced in Fedora 29, which is EOL since November 2019.  I think it is time to remove them now.

Comment 4 Freddy Jensen 2020-09-09 14:21:47 UTC
Hi Kamil,

Yes, my installer script requires all those tools you listed.
Those tools are core Unix commands that have been around in
all Unix'es for ever. They will not go away. If they are ever
removed from a distro, then scripts all over the world will

In fact, my installer will check for the existence of these
tools before it starts the install:


I hope this helps.


Comment 5 Kamil Dudka 2020-09-09 15:04:01 UTC
Sorry for the confusion!  None of the tools from coreutils is going to be removed, only the mentioned virtual provides in RPM metadata.

As I understand it, your script does not use RPM metadata at all.  So the proposed change should not break it.

Comment 6 Freddy Jensen 2020-09-09 15:19:16 UTC
Yes, that is correct. It does not look at rpm metadata at all
so there are no dependencies.

There is a list of rpm prerequisite packages (93 packages)
that the installer installs, using the dnf command.


Comment 7 Freddy Jensen 2021-05-23 04:11:08 UTC
From: Freddy Jensen
Date: 2021-05-21:
Subj: New installer for Acrobat Reader for Linux

 I have updated the Acroread Linux installer to support Fedora-34.
 Please find the new release here:


 1) Go into the folder: Acrobat/Acroread/Linux-Installer/2021-05-21-Version-1.0.3

 2) Copy the two files: acroread.tar and readme.txt

 3) Follow the instructions in readme.txt



Comment 8 Hin-Tak Leung 2021-05-27 19:41:36 UTC
While I appreciate the effort, I don't think it is legal / advisable to re-distribute / re-package Adobe binaries you did not build; on the other side, sorry to say this, I personally would not install any random binaries from random people posting their work on dropbox.

A more acceptable alternative is to create a "acroread-companion" rpm, which depends on coreutils and provides whatever the adobe rpm needs, and post the acroread-companion rpm in source form. (and a compat-libidn11 would be nice too... but from the "official" channels).

That said, "rpm --nodeps ..." has always worked (and 'rpm2cpio ... | cpio --extract -m -d' to get at specific files), for those who really want a binary rpm and willing to jump through some hassles...

Anyway, there are at least 3 independent implementations of pdf viewers on linux: the xpdf/poppler camp, the mupdf camp, and the ghostscript camp. Unless you really want the Adobe one, any of these do a reasonable job.

I myself wanted the adobe one, because I was for a time working with/for the mupdf/ghostscript parties, and needed/wanted
the "official adobe" renditions for comparison sometimes. Most people don't have this need.

Comment 9 Freddy Jensen 2021-05-27 23:48:47 UTC
Hi Hin-Tak Leung,

Thank you for your note. It is correct that if you build
your own product and include Adobe binaries, and then
link it together as a binary or some other proprietary
format, then it is questionable, and not such a good

However, in this case everything that I have added to
create the new acroread.tar is completely open source.

If you unpack the tar file, you will see that it contains
the original Adobe rpm file plus some source files.

So in this case I could have delivered the new installer
as a folder with all these source files plus Adobe's
rpm file, and there would not be any question about
whether it was legal or not.

What I did, was simply to package up that folder as a
tar file and a readme file to make it much easier to
copy and install. So therefore, the legality is the
same whether I deliver it as a folder or I package
it up as a tar file.

Now, if I had packaged it in a proprietary format and
provided a proprietary binary to read that file, then
it would be problematic, and even more problematic
if I charged money for it.

Another thing to consider is that fact that Adobe's
rpm file is provided at no cost and it can easily
be unpackaged by using rpm2archive followed by a
tar command.

So you can see that everything I have done is completely
transparent and open. Anyone can add to it or change it
if desired, as long as nobody charges any money for it,
and as long as nobody re-packages it into a proprietary
closed format.

I hope that clarifies it.

In conclusion I will say that Hin-Tak Leung is completely
justified in raising this question and I thank you for
the opportunity to clarify it, and apologize that I
did not make this clear from the beginning.

I worked 25 years for Adobe as a developer on Acrobat
and Acrobat Distiller, and we always had to be mindful
of these legal issues and make sure that everything
was in compliance.

Thank You

Freddy Jensen

Comment 10 Kamil Dudka 2021-05-30 14:40:20 UTC
I agree that Red Hat Bugzilla should not be used for advertising binary distribution of 3rd party non-free software.  Red Hat does not recommend (or ever support) the solution you refer to.  Please use an appropriate channel for announcements like this.

Comment 11 Douglas Kosovic 2023-04-12 02:17:36 UTC
I've created an AdobeReader.spec RPM spec file and instruction on how to generate a new AdobeReader-9.5.5-2.i686.rpm binary RPM as a non-root user (from the original AdbeRdr9.5.5-1_i486linux_enu.rpm file), see:

The /bin/basename dependency has been replaced with coreutils and a few other dependencies have also been fixed. The new binary Adobe Reader RPM can be installed using dnf without issue.

I still find acroread useful with cups-filters 1.x which includes a pdf2ps filter that can be configured to use acroread to convert PDF to PostScript Level 3, especially with proprietary clone PostScript interpreters on some printers that barf with the PostScript Level 2 generated by ghostscript's pdftops. I also tried the other opensource alternatives, but they sometimes have issues with ingesting the PDFs sent to the print server or other issues.

After going down the rabbit hole of generating a new Adobe Reader binary RPM, I tried Freddy's Acrobat Reader installer on a VM and got some inspiration on how to handle the .desktop, mime files and icon files, which saved me a bit of time.

Comment 12 Kamil Dudka 2023-04-12 07:05:29 UTC
Douglas, please read comment #10.  The Fedora/coreutils component in Red Hat Bugzilla is not the appropriate place for such announcements.  Thanks for understanding!

Note You need to log in before you can comment on or make changes to this bug.