How can I satisfy dependencies with manually installed packages?

I installed TeX Live 2019 using tug.org’s installer instead of DNF, then I messed it up by inadvertently installing TeX Live 2018 as a dependency while installing R with DNF.

How can I reassure DNF that TeX Live is there in my system?

I think one solution is to fake the texlive package, but how can I do it?

I don’t think there’s a way to fake the package. Your best bet is to uninstall it, then reinstall it properly, using dnf. Not only will this avoid dependancy hell, it will let dnf update it as needed.

1 Like

+1

Your best bet here is to install stuff from non Fedora sources to non-standard paths, such as /opt, which the rpms will never write to, and then load them using your environment variables and so on. Faking the complete texlive package is far from trivial. It is perhaps the most complex package in the Fedora repositories at this time: texlive.spec

So, if you want R from Fedora to work, you will have to let dnf install the required dependencies, even if you later use your own installation of texlive instead.


dnf can only find dependencies that are listed in the rpm packages as metadata. You can see what each rpm requires using

rpm -qp --requires <complete path to the rpm package>`

This only works if you have the package installed, or if you have the rpm file downloaded.

When repositories are created, this information is extracted and included in the metadata for each repository. dnf downloads this and then figures out how to go about setting up a complete transaction where all dependencies are satisfied. If they aren’t, it’ll tell you that there are missing requires and so on. You can get this type of information using the dnf repoquery plugin:

sudo dnf repoquery --whatprovides <package or some other capability listed as provides in rpm metadata>

R-core, for example, requires:

$ sudo dnf repoquery --requires R-core
/bin/bash
/bin/sh
cups
gawk
ld-linux-x86-64.so.2()(64bit)
ld-linux-x86-64.so.2(GLIBC_2.2.5)(64bit)
ld-linux.so.2
ld-linux.so.2(GLIBC_2.1)
less
libRblas.so
libRblas.so()(64bit)
libRmath(x86-32) = 3.5.3-1.fc30
libRmath(x86-32) = 3.6.0-1.fc30
libRmath(x86-64) = 3.5.3-1.fc30
libRmath(x86-64) = 3.6.0-1.fc30
libX11.so.6
libX11.so.6()(64bit)
libXmu.so.6
libXmu.so.6()(64bit)
libXt.so.6
libXt.so.6()(64bit)
libbz2.so.1
libbz2.so.1()(64bit)
libc.so.6(GLIBC_2.27)(64bit)
libc.so.6(GLIBC_2.28)
libcairo.so.2
libcairo.so.2()(64bit)
libcurl.so.4
libcurl.so.4()(64bit)
libdl.so.2
libdl.so.2()(64bit)
libdl.so.2(GLIBC_2.0)
libdl.so.2(GLIBC_2.1)
libdl.so.2(GLIBC_2.2.5)(64bit)
libgcc_s.so.1
libgcc_s.so.1()(64bit)
libgcc_s.so.1(GCC_3.3.1)
libgcc_s.so.1(GCC_3.3.1)(64bit)
libgfortran.so.5
libgfortran.so.5()(64bit)
libgfortran.so.5(GFORTRAN_8)
libgfortran.so.5(GFORTRAN_8)(64bit)
libgobject-2.0.so.0
libgobject-2.0.so.0()(64bit)
libgomp.so.1
libgomp.so.1()(64bit)
libgomp.so.1(GOMP_1.0)
libgomp.so.1(GOMP_1.0)(64bit)
libgomp.so.1(GOMP_4.0)
libgomp.so.1(GOMP_4.0)(64bit)
libgomp.so.1(GOMP_4.5)
libgomp.so.1(GOMP_4.5)(64bit)
libgomp.so.1(OMP_1.0)
libgomp.so.1(OMP_1.0)(64bit)
libicui18n.so.63
libicui18n.so.63()(64bit)
libicuuc.so.63
libicuuc.so.63()(64bit)
libjpeg.so.62
libjpeg.so.62()(64bit)
libjpeg.so.62(LIBJPEG_6.2)
libjpeg.so.62(LIBJPEG_6.2)(64bit)
liblzma.so.5
liblzma.so.5()(64bit)
liblzma.so.5(XZ_5.0)
liblzma.so.5(XZ_5.0)(64bit)
libm.so.6
libm.so.6()(64bit)
libm.so.6(GLIBC_2.0)
libm.so.6(GLIBC_2.1)
libm.so.6(GLIBC_2.2.5)(64bit)
libm.so.6(GLIBC_2.23)
libm.so.6(GLIBC_2.23)(64bit)
libm.so.6(GLIBC_2.27)
libm.so.6(GLIBC_2.27)(64bit)
libm.so.6(GLIBC_2.29)
libm.so.6(GLIBC_2.29)(64bit)
libpango-1.0.so.0
libpango-1.0.so.0()(64bit)
libpangocairo-1.0.so.0
libpangocairo-1.0.so.0()(64bit)
libpcre.so.1
libpcre.so.1()(64bit)
libpng16.so.16
libpng16.so.16()(64bit)
libpng16.so.16(PNG16_0)
libpng16.so.16(PNG16_0)(64bit)
libpthread.so.0
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.0)
libpthread.so.0(GLIBC_2.2)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libreadline.so.8
libreadline.so.8()(64bit)
librt.so.1
librt.so.1()(64bit)
librt.so.1(GLIBC_2.2)
librt.so.1(GLIBC_2.2.5)(64bit)
libtcl8.6.so
libtcl8.6.so()(64bit)
libtiff.so.5
libtiff.so.5()(64bit)
libtiff.so.5(LIBTIFF_4.0)
libtiff.so.5(LIBTIFF_4.0)(64bit)
libtk8.6.so
libtk8.6.so()(64bit)
libtre.so.5
libtre.so.5()(64bit)
libz.so.1
libz.so.1()(64bit)
make
openblas-Rblas
perl-interpreter
redhat-rpm-config
rtld(GNU_HASH)
sed
tex(dvips)
tex(latex)
unzip
vi
xdg-utils

It requires tex(dvips) and tex(latex) which are provided by the Fedora texlive installation. Confirmed by looking at the spec file here: https://src.fedoraproject.org/rpms/R/blob/master/f/R.spec#_261

You could file a bug asking the maintainer to make these optional dependencies if know that they are not required by R all the time. (I don’t know R well enough to know this.)

(If you can confirm that these are the only tex requirements for the complete R suite, you can write yourself a new fake package and make it provide these two capabilities. I would not suggest it, though, and cannot say exactly how much work it’ll take. I would not expect it to be a trivial undertaking)

2 Likes

It’s not so simple with TeX Live. The vanilla version uses its own updater program, tlmgr, which distros omit in their package. This way though, distros’ packages end up being always one version (one year) behind. You can read here for more information: https://www.texdev.net/2011/10/29/tex-live-in-linux-distributions/

Long story short, for me the proper way to install is with the TUG installer, that is out of discussion.

1 Like

Sure. Texlive 2019 was released at the end of April: 29 April 2019 (http://www.tug.org/texlive/) and will be updated in Fedora (and other downstream distributions) at some point in the future. It really isn’t a trivial undertaking. If you want the latest version, you will have to install it yourself using their installer.

Fedora is no longer a “bleeding edge” distribution. The community is trying very hard to balance providing latest versions of software while keeping the whole distribution stable enough for end users. We maintainers, therefore, follow this policy that FESCo set out:

https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases

So, I think texlive 2019 will only land in the next release: Fedora 31. (I’ve not spoken to the maintainers, however)

Keeping two installations and having to fiddle with environment variables to make only one of them work is less than ideal. I’ve done a bit of research and I’ve found these two approachs to be the most promising, in my view:

  • using a prebaked dummy package, such as those in the CTAN, or in this Copr repository: fatka/ texlive-dummy;
  • downloading the dependency’s rpm file and running rpm --justdb on it [source].

Do you have any suggestions? I’ve seen you have some experience with this issue :wink:.

It comes out that my TUG installation in /usr/local/ is fine after removing R and its dependencies :relieved:.

I don’t think the problem lies in the package. Also, even if the dependency was removed from the R package the problem would remain for other packages.

I think the cleanest solution, in principle, is to be able to tell DNF that the executables provided by the dependencies are available in the system (and where they are to be found). I don’t know how feasible it is to provide an easy interface for this (maybe something like equivs in Debian, though I don’t remember how it worked), so I don’t know if it would make for a reasonable feature request.

By the way, what do you mean by “optional dependencies”, weak dependencies?

Also, thank you for the explanation about how DNF works.

The dummy package way

A dummy TeX Live package satisfies the dependencies that involve TeX Live components without actually installing anything new on the system.

Use the appropriate package among those listed on CTAN. For Fedora 30 I used the dummy package made for RHEL7.

Unzip the archive and run

 sudo dnf install /path/to/texlive-dummy *hit TAB*

Then you should be able to install another package that depends on TeX without pulling down tons of dependencies.


Notes:

If a dummy package for your manually installed software isn’t available

Then you might try Fakeprovide. I had given it a quick try and it looks like it doesn’t handle meta-packages, that is to say, as far as I understand, you can’t just fakeprovide texlive-scheme-full in order to provide a bunch of TeX Live capabilities, rather, you need to run Fakeprovide on each of the required packages.

Another possible approach – which I have not tested – would be to download the dependency’s rpm file with dnf download <package> (you can find which one is required with a combination of dnf repoquery --requires <package (e.g. R-core)> and dnf repoquery --whatprovides '<capability (e.g. tex(latex)>') and then (pseudo-)installing it with rpm --justdb <file>.rpm, which should just update DNF’s database without actually creating any new file. See https://www.redhat.com/archives/rhl-devel-list/2008-August/msg00927.html.

Anyway I don’t think TUG’s TeX Live installer is guaranteed to cover all that’s in, say, texlive-scheme-full (and viceversa), so I guess using CTAN’s dummy package, which is written by people that know what TeX Live provide, is the safest path toward dependency peace.

1 Like