Bug#1071783: Bug#1071762: texlive-base: tlmgr documentation omissions, inaccuracies, and pitfalls
> 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?
Bug#1071783: Bug#1071762: texlive-base: tlmgr documentation omissions, inaccuracies, and pitfalls
Hi Manny, On Sat, 25 May 2024, Manny wrote: > In that case it should not exist in Debian. A pkg in the official > Debian repo should never be unsupported by Debian because Debian > support staff use inclusion of software in official repos as the > defining factor as to whether they support an app. It allows installing packages into $HOME/texmf by setting up tlmgr user mode with tlmgr init-usertree This is *ALL* documented. > Alternatively, I think it would be fair to say there is limited > support if its existence persists in Debian, but that needs to be > defined. Debian users are receiving documentation and a tool that does > not work as documented. There are two reasonable options: fix the tool > or fix the docs. Incorrect. Debian tlmgr runs in usermode, and the documentation of tlmgr clearly states under the heading of usermode that not all actions are supported. > I certainly do not mean to try to push any work on anyone, but one of > those directions should at least be selected as a goal to work > toward. Fixing the docs, IMO, could be a matter of explicity listing No need. Just read the section on usermode. > Otherwise, how do testers even know what is a reportable bug and what > is not? How does a user know whether tlmgr can help them before they > spend much time on it? The docs are not doing their job. Reading the output of tlmgr, and reading the man page. tlmgr states clearly that it switches to usermode. The man page states clearly that one has to run init-usertree first. The man page states clearly that only a few commands are supported by usermode. > The README.tlmgr-on-Debian.md (which escaped me before my first 2 bug > reports) is a good start on this and gives a good overview of the > situation. But what’s missing is a list of functionality Debian users > can expect to work. Read the man page. > I got the /info/ action partially working after you mentioned a > specific mirror URL. You had to mention a specific URL because the > docs are missing that information. The docs point to Incorrect again. tlmgr told you that the remote repository is too new. At the time when tl 2022 was released for Debian, the repository was the correct one. > I still stumbled. When visiting that directory, all the files therein > are installation and upgrade scripts, which intuitively seems Please, look a bit more carefully. There is a directory tlpkg which contains the tlpdb, and a directory for the actual packages. > incorrect for a repository location to supply to a package manager, so > I first tried supplying this URL instead: > > https://pi.kwarc.info/historic/systems/texlive/2022/ > > which failed: Yes, because you didn't read what I wrote: > So for 2022 you can for example >https://pi.kwarc.info/historic/systems/texlive/2022/tlnet-final/ This included the correct tlnet-final > $ tlmgr --usermode info --only-installed > (no output) Yes, as I told you, tlmgr cannot be used to give information about the GLOBAL installation, only about the packages that are installed in usermode, that is into the initialized usertree. You don't have any package installed. So the above output is correct. What do you expect? Again, please read the usermode section. > It still failed to list locally installed packages and > versions. Omitting --only-installed now has output but the list is See above. tlmgr works ONLY on your TEXMFHOME > So “info --only-installed” is still broken. I cannot think of a more It is not. It does *exactly* what it is supposed to do. List the packages you have installed via tlmgr into $TEXMFHOME. > A package manager that runs as a user when launched by root is > inherently a dodgy situation because the root account should not be I don't know what you are talking about. I have TeX Live installed into ~/tl/2024 and can use tlmgr as user. No root involved. > We expect the powers of root to be needed for tlmgr operations because > we expect it to perform systemwide ops. But if root’s powers are not No. tlmgr *CANNOT* and is *FORBIDDEN* to change files that are installed by apt. Full stop. > After my attempt to run tlmgr as root forced me into user mode, I No need to run as root. > What’s astonishing here is that tlmgr is provided with the Debian > texlive pkg, so it’s consequently implied that it’s meant to work with > the Debian texlive installation that it is packaged with. Software Yes, in usermode, clearly stated in the output of tlmgr. I think I mentioned that already? > When a Debian sanctioned package manager comes with apps that the pkg > manager manages, it has the ability to manage those pkgs. It think > emacs package manager might be an example of that. Huu, pip can manage your packages, but not if you install then via apt install python-foobar That is the same situation. BTW, for many years I **did** exclude tlmgr from the Debian packages, and only on great pressure from Debian users I implemented the "usermode"
Bug#1071783: Bug#1071762: texlive-base: tlmgr documentation omissions, inaccuracies, and pitfalls
> All the three bugs boil down to the same: > > tlmgr is NOT supported if you install it via Debian. > Only VERY REDUCED functionality is provided, as you found. In that case it should not exist in Debian. A pkg in the official Debian repo should never be unsupported by Debian because Debian support staff use inclusion of software in official repos as the defining factor as to whether they support an app. Alternatively, I think it would be fair to say there is limited support if its existence persists in Debian, but that needs to be defined. Debian users are receiving documentation and a tool that does not work as documented. There are two reasonable options: fix the tool or fix the docs. I certainly do not mean to try to push any work on anyone, but one of those directions should at least be selected as a goal to work toward. Fixing the docs, IMO, could be a matter of explicity listing the features that function in Debian while listing the dysfunctional features (in a “KNOWN BUGS” section, for example). Otherwise, how do testers even know what is a reportable bug and what is not? How does a user know whether tlmgr can help them before they spend much time on it? The docs are not doing their job. The README.tlmgr-on-Debian.md (which escaped me before my first 2 bug reports) is a good start on this and gives a good overview of the situation. But what’s missing is a list of functionality Debian users can expect to work. > For example, tlmgr info does not work because we don't have a tlpdb > at hand. I got the /info/ action partially working after you mentioned a specific mirror URL. You had to mention a specific URL because the docs are missing that information. The docs point to https://ctan.org/mirrors/mirmon but that page also neglects to mention historic versions. Even though you gave this specific URL: https://pi.kwarc.info/historic/systems/texlive/2022/tlnet-final/ I still stumbled. When visiting that directory, all the files therein are installation and upgrade scripts, which intuitively seems incorrect for a repository location to supply to a package manager, so I first tried supplying this URL instead: https://pi.kwarc.info/historic/systems/texlive/2022/ which failed: ===8< /usr/bin/tlmgr: TLPDB::from_file could not initialize from: https://pi.kwarc.info/historic/systems/texlive/2022//tlpkg/texlive.tlpdb /usr/bin/tlmgr: Maybe the repository setting should be changed. /usr/bin/tlmgr: More info: https://tug.org/texlive/acquire.html ===8< There seems to be a presumption of TeX expertise on users. So then I tried the path verbatim as you suggested: ===8< $ tlmgr option repository https://pi.kwarc.info/historic/systems/texlive/2022/tlnet-final/ … $ tlmgr --usermode info --only-installed (no output) ===8< It still failed to list locally installed packages and versions. Omitting --only-installed now has output but the list is misleading. I believe the list of packages given by the /info/ action with no options should show /both/ locally installed packages and remotely available packages. It gives a package list without indicating whether they are locally installed or remotely available. I can only speculate based on use of the --only-installed switch that the unconstrained list is actually purely remotely available packages. So “info --only-installed” is still broken. I cannot think of a more basic function that users would expect to work. The default repository on Debian should not be https://mirror.ctan.org/systems/texlive/tlnet because that’s broken out of the box. The working repo URL probably changes as time passes and/or as the package moves from testing to stable, which makes it tricky. But the docs should compensate by covering that. > > “(running on Debian THUS switching to user mode!)” > > Yes, that is the meaning. I think this is obvious enough., It’s not obvious because even when it’s fully understood that Debian implies user mode, it’s still an astonishing circumstance for both users and admins. Users expect to be in a user mode inherently, but not in the slightest as a consequence of the distro they are working on. Even if “thus” replaced the comma, root users will be in disbelief. The ambiguity of the comma worsens that and exacerbates the disbelief. Debian is designed for systemwide installations of multi-user software that is controlled by root, and texlive is installed as such, not as a user. So users and admins do not expect Debian to be a reason for being put into user mode. A package manager that runs as a user when launched by root is inherently a dodgy situation because the root account should not be running apps like latex. Thus root should not generally be doing a /user/ installation of a tool like texlive for themself, for the admin’s own use. Root running user apps not for admin work is
