Arch Linux User Repository

As this package is quite big (currently around 2.4GB uncompressed) I recommend changing your makepkg.conf settings to use a low compression level and multi-threaded compression by setting either

COMPRESSXZ=(xz -T 0 -c -z -0 -)

or even faster

COMPRESSZST=(zstd -q -c -z -1 -T0 -)
PKGEXT='.pkg.tar.zst'

The new package texlive-doc seems to work.

The nice thing about this AUR package is that updates use the network efficiently, in that unchanged parts do not need to be transferred.

To get the same effect with texlive-doc, build the pkgbase texlive-texmf from source (using makechrootpkg). It uses SVN sources (texmf-dist), which makes me hope for similar update efficiency.

The current SVN checkout size is 18GB, but from that you can build all the texlive-* packages except texlive-bin which has a different pkgbase and different VCS sources.

By the way: I may have overlooked something, but since asp has been discontinued, the new pkgctl-based way of accessing PKGBUILD for standard Archlinux packages seems to require (1) creating an account on gitlab.archlinux.org and (2) creating an unrestricted API access token, both of which I find both irritating and concerning. There should be an anonymous git+https way.

Thanks for the info. I guess in this case this package is obsolete. I will mark it as obsolete and as soon as I get to try out the texlive-doc from extra might as well delete this.

Now users can install the texlive-doc from extra repo.

This conflicts with the most recent texlive-bin update to 2023.66984-2:

texlive-bin: /usr/share/texmf-dist/doc/bibtex8/csfile.txt exists in filesystem (owned by texlive-most-doc)
texlive-bin: /usr/share/texmf-dist/doc/bibtex8/file_id.diz exists in filesystem (owned by texlive-most-doc)
texlive-bin: /usr/share/texmf-dist/doc/bibtexu/README exists in filesystem (owned by texlive-most-doc)
texlive-bin: /usr/share/texmf-dist/doc/bibtexu/examples/test.bbl exists in filesystem (owned by texlive-most-doc)
texlive-bin: /usr/share/texmf-dist/doc/bibtexu/examples/test.bib exists in filesystem (owned by texlive-most-doc)
texlive-bin: /usr/share/texmf-dist/doc/bibtexu/examples/test.pdf exists in filesystem (owned by texlive-most-doc)
texlive-bin: /usr/share/texmf-dist/doc/bibtexu/examples/test.tex exists in filesystem (owned by texlive-most-doc)
texlive-bin: /usr/share/texmf-dist/doc/chktex/ChkTeX.pdf exists in filesystem (owned by texlive-most-doc)
texlive-bin: /usr/share/tlpkg/texlive.tlpdb exists in filesystem (owned by texlive-most-doc)

The version number of this package is set to the current date when it is built. To update, just use makepkg to download the most recent documentation and create a new package, then install it, or use your favourite AUR helper.

There used to be a version of this package "20210224-1" newer than the current version "20200622-1". Did something happen requiring a downgrade, or is the version number simply non-incremental?

@velleto: Thanks for the suggestion. I have tried it, and it surely looks nice. But then

• there is no longer a summary with the rsync speedup (which is important for the justification of the rsync-based approach)
• the *-build.log now has twice the size and contains lots of CRs
• there is no longer the possibility to glimpse a curious package name, e.g. multienum, causing me to launch texdoc multienum while awaiting completion

All these are matters of taste, but I have reverted my checkout to -v again.

Could I suggest changing the rsync flag -v to -h --info=progress2 --no-i-r?

The -h --info=progress2 will give (human readable) progress of the entire transfer (not for individual files), and the --no-i-r forces rsync to calculate the entire transfer queue before transfer, ensuring that the printed statistics are accurate. (When incrementally recursing, rsync doesn't know how many files are left to transfer at any given time and the progress indicator tends to yo-yo up to 100%, and then back down to, say, 20% when rsync realises that there are more files to transfer).

With such a large download, I find it more useful to see statistics of the entire transfer progress, rather than seeing hundreds of file names being scrolled across my screen.

A current workaround (other than editing the PKGBUILD manually) would be to send the SIGVTALRM signal to the rsync process (crudely send to all: kill -s SIGVTALRM $(pgrep rsync)) to generate a one-time overall progress report after the current file has finished transferring.

Thank you

I agree this should not flag an error from what I can tell it is using the the PKGBUILD version and comparing it to the build from texlive so each time texlive has a new release the PKGBUILD would have to be updated. There was a new release just a few days ago I think that is what is causing the issue and by changing the PKGBUILD version it should be good until the next texlive release. Really just wanted to have a comment here in case anyone had an issue and noticed the error. It will still build and install fine but the error will persist until the PKGBUILD is updated.