Still need to build and test the extra packages, and to update
net space if necessary.
But first Mr Grumpy is going to sulk, before looking at why his
updated latex-tests tarball appears to think ghostscript has not
been installed.
Show minimum (85 MB plain TeX with luatex only for the scripts which
support texlive, an estimate for latex and later engines: I got
2.1 GB with scheme-basic + collection-latexrecommended, or 2.2 GB
with scheme-medium (very different packages), I guess up to 4 GB
for people who make a lot of use of the modern engines. 8.6 GB
for everything.
Show the binary size for ConTeXt in the note on the page for texlive
source - unless somebody wants to maintain ConTeXt I guess that
information need not be updated in future years.
New version latex-test-20240317 : In the previous version I had
assumed that kpsepath (part of TLCore) would always be present
when looking for TTF and OTF fonts, and failed with an error if
it was missing.
Testing a much smaller binary install yesterday showed it is NOT
always present - the only schemes containing it are medium and
full. Now fixed, my tests with e.g. basic plus the latexextra
and latexrecommended collections now run.
Also update the version in th comment re testing asymptote.
Since I am increasingly suggesting that anyone wanting to install
the binary might prefer to do it as a normal user, clarify that
root should not do any updates.
At the start of 'setting the PATH' explain why we do things like
this, and mention that we used to bootstrap the source build - that
is to give a clue if a reader decides they want to install ConTeXt
and LuaMetaTeX where I suggest doing a similar thing.
Explain why context is not present.
In the the unlikely event that somebody wishes to build context
from source, link to my old comments in the 2023 ticket, and to
the source tags at github.
Also mention that first installing (only) context from the binary
sounds like the easiest way to do this - the way we used to use the
full binary to bootstrap the source build.
Change a lingering 'command' to 'parameter' in the explanations.
Replace ConTeXt with LuaLaTeX ininitial comment about what is
included - lualatex is commonly used, context is very niche.
Add a note for any future ConTeXt users.
Remove warning about the need to update 2023 lualatex etc.
Not yet installed, tested, or measured.
Texlive source: Fix up the tarball names, year, tarball names,
md5sums, sizes. Do not patch the source.
The links have not neen tested, and I have not yet attempted to
build this.
Like other texlive "extras", this overwrites various files on
texmf-dist. I'm now showing the net change (for this version of
this package in 2023 it is essentially only adding the program),
with a comment about the space used for a DESTDIR install.
On the 2023 source it works in my texlive tests without any
warning (the latest binary gave a warning and I was not sure
if that had worked) - it seems that using 'display' from ImageMagick
might have been the problem (always an unusual way of showing an
svg file), using firefox works ok.
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).
