coreutils-8.29-7.fc28.x86_64 provides /bin/basename, coreutils-8.30-5.fc29.x86_64 does not. Version: coreutils-8.30-5.fc29.x86_64 +++ 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): libidn-1.35-3.fc29.i686 libidn-1.35-3.fc29.x86_64 How reproducible: always Steps to Reproduce: 1. Try to install adobe acrobat reader... 2. 3. 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.
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.
2020-09-08-Version-1.0.0 I have posted a fix for this problem. Please see: https://www.dropbox.com/sh/bo2ebl8z2gkyjm9/AAA4mkjg52Kf4mk_UbSyQoyKa?dl=0 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
Freddy, does your solution rely on any of these provides? https://src.fedoraproject.org/rpms/coreutils/blob/441f1d75196db5609a4ea1627c3a34192785372d/f/coreutils-provides.inc#_3 They were introduced in Fedora 29, which is EOL since November 2019. I think it is time to remove them now.
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 brake. In fact, my installer will check for the existence of these tools before it starts the install: awk cat chmod cksum cp diff dnf echo grep ln mkdir rm rmdir rpm2archive sed sleep tar touch tr uname update-mime-database wc whoami I hope this helps. Freddy
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.
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. Freddy
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: https://www.dropbox.com/sh/bo2ebl8z2gkyjm9/AAA4mkjg52Kf4mk_UbSyQoyKa?dl=0 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 Enjoy Freddy
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.
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 idea. 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
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.
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: https://github.com/eait-cups-printing/adobe-reader-rpm 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.
Douglas, please read comment #10. The Fedora/coreutils component in Red Hat Bugzilla is not the appropriate place for such announcements. Thanks for understanding!