This does NOT fit into 'works properly', nor into 'not tested'.
I've tried
ln -sv /usr/lib/libcrypt.so.2 /usr/lib/libcrypt.so.1
but on my system that complains about GLIBC~_2.2.
iAlso, dvisvgm does not work properly on my tests which worked
in last August, it reports
The old, written in PostScript, PDF interpreter has been removed entirely.
You should cease using -dNEWDPF as it has no effect npre-processing DVI
file (format version 2)
And although svg files were produced, they missed some details.
I will find out later this week whether my test files need to be
updated for current dvisvgm *after* I have built TL2023 source.
Upstream documentation is not clear whether to use
https://cdn.docbook.org (in recent docs) or the http form (in older docs
and in the sample xml catalog distributed with the package). So have
both in our catalog file.
Without this setting, when opening a .dvi file with evince:
- If PATH does not contain /opt/texlive/2023/bin/x86_64-linux, it just
fails.
- If PATH contains /opt/texlive/2023/bin/x86_64-linux, the file can be
opened but a stupidly long time is used.
In both cases there is a warning message on the console:
warning: kpathsea: configuration file texmf.cnf not found in these
directories: ... ... ...
Setting TEXMFCNF explicitly fixes the issue (regardless PATH contains
the texlive bindir or not; though I'm not sure why libkpathsea cannot
use a reasonable default).
The texlive binaries are built with RPATH, thus they work fine w/o
ld.so.conf modification.
For other packages using kpathsea we need to symlink libkpathsea.so.6 to
/usr/lib so it can be found.
It seems install-tl-unx does not use texlive shared libraries at all (I
downloaded the tex executable from it and the executable only uses
libc.so.6 and libm.so.6).
We don't carry the frontends anymore due to the GTK+-2 dependency (and
Simple-Scan replaces that functionality), so we don't need to specify
that sane-backends installs these programs/libraries anymore.
neither firefox nor epiphany can download them, and they are not
well maintained, because rarely tested.
This is WIP because the "(HTTP)" part of "Download (HTTP)" will
need to be removed too.
But let's see what users think first...
The layout of distfiles.gentoo.org has suddenly changed. Let's just
stop using it (or we need to include a two-bit prefix of some hash in
the URL and IMO doing so is just stupid, as we can always use http
instead).
