> You don't have any package installed. > So the above output is correct. > > What do you expect?
I have had this file installed since 2015: ~/.local/share/texmf/tex/digsig.sty tlmgr did not find it. But tlmgr found that tree because it added a DB next to it: ~/.local/share/texmf/tlpkg/texlive.tlpdb There is also a problem installing the 2021 version of acro: ===8<---------------------------------------- $ torsocks tlmgr --usermode --repository rsync://tug.org/historic/systems/texlive/2021/tlnet-final/ install acro TLPDB: not a directory, not loading: rsync://tug.org/historic/systems/texlive/2021/tlnet-final/ tlmgr: Cannot load TeX Live database from rsync://tug.org/historic/systems/texlive/2021/tlnet-final/ $ torsocks tlmgr --usermode --repository https://pi.kwarc.info/historic/systems/texlive/2021/tlnet-final/ install acro xz: (stdin): Unexpected end of input tlmgr: The TeX Live versions supported by the repository https://pi.kwarc.info/historic/systems/texlive/2021/tlnet-final/ (2016--2021) do not include the version of the local installation (2022). ===8<---------------------------------------- The first attempt used the German repo https://www.tug.org/historic/. If that host is the basis of the mirrors, why would the directory structure be different? This seems to be implied by the error message, but unlikely, so the error message might be wrong. The 2nd attempt used a path that I could test using a browser. The xz error came relatively quick, then it seemed to hang. It was unclear what it was doing. This makes me nervous because I am on a measured rate connection. A big download can be costly for me. When a download manager or package manager does not state the size of what will be fetched in advance, users on limited connections have to decide between walking away or gamble and give a blank cheque. I started looking at a bandwidth meter and I could see that ~15mb was being fetched from the time I started looking. The acro package is under 1.5mb including the docs. There was no indication of what it was fetching -- could be all of texlive for all I know. There could be dependencies to fetch, but tlmgr does not communicate this to the user. I was getting ready to cancel it but then it finished at the 15mb mark before I could kill it. The output is a mystery. I think it’s attempting to give an error. It’s clear that acro was not added to ~/.local/share/texmf/tex/. My choice to install the previous version of acro is deliberate and tlmgr seems to assume I want the version I already have despite my express instructions. I wonder if this apparent protection mechanism can be overridden with --force. The man page for --force says: “If updates to "tlmgr" itself (or other parts of the basic infrastructure) are present, "tlmgr" will bail out and not perform the installation unless this option is given. Not recommended.” That would seem apply to my situation. It would be more clear if the error output would also tell the user that --force could be used. Or better, if it would prompt the user for feedback. Because apparently the downloaded data was thrown away. The ~/.local/share/texmf/ does not have the acro tarball. I also tried: $ find .cache/ -name acro.tar.xz which came up empty. I would rather not experiment too much because every attempt is another ~15+ mb. I have to wonder as well what this apparent protection mechanism is protecting from. In normal mode, it’s understandable that you would not want mismatched versions to ruin a whole systemwide installation. But in usermode, you inherently have a sandbox or degree of isolation anyway, particularly when there is nothing in ~/.local/share/texmf/ that tlmgr is aware of. When running in user mode, shouldn’t the installation only stop if there is a conflict with another local user-specific object?
