> 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 widely regarded as an abuse of how the root account should be used. The root account would only run tlmgr for the purpose of maintaining system-wide apps for the users. So instead of switching to user mode, tlmgr should probably abort (with useful information) when root runs it. 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 needed, then root should not be running tlmgr at all and root should be made aware of that. After my attempt to run tlmgr as root forced me into user mode, I thought perhaps there is a specific account for texlive management. But /etc/passwd showed nothing obvious. > > many Debian users would not want to update the whole texlive > > installation outside of the apt manager. Ideally, apt would have > > Don't use tlmgr on Debian if you are not happy with the insufficiences. The problem is that significant effort is required for the users to discover the insufficiencies and inconsistency with docs. Lengthy experimentation is needed before users can realize whether or not tlmgr can serve them as advertised. Users need to know relatively quickly what to expect. The tlmgr.pdf leads users to believe the tool will work. > the files are installed by root and apt. > tlmgr can do this when you run upstream TeX LIve, but NOT Debian TeX > Live. 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 outside the Debian repos is branded in Debian’s guides as “non-Debian” and unsupported. This is apparently a Debian packaged thing that only manages non-Debian software. There are other instances of that, e.g. with python’s pip/pip3/pipx tools, but those tools pass the rule of least astonishment because they do not come packaged with a software collection that would lead people to expect it to manage. 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. > There is nothing to do about this, tlmgr is the configuration management > system for TeX Live as it is provided by upstream. It conflicts with > apt/dpkg. Trying to do a few things by setting it to user mode does > not fix all the other problems. Wouldn’t it make sense for tlmgr to be excluded from texlive-base, and have it packaged separately? A separate package is how pipx is organised. As a separate package users would have a fighting chance of not inherently expecting it to work with the Debian texlive installation it comes with. They would still have some degree of false expectation as they approach it, but the package description could then clarify and state it’s specifically for managing a separate non-Debian texlive installation. Users would have to proactively seek out tlmgr in that case. In my case it was probably a web search that made me aware of tlmgr. Then I saw that it was already installed on my system, and ran “texdoc tlmgr”. This path paved the way of false expectations. The torbrowser-launcher pkg is another example of a Debian pkg that installs non-Debian software. If tlmgr were separately packaged with a pkg name like “non-debian-texlive-installer”, that would help reduce the number of accidental users.
