This is an attempt to list the locally install pkgs:

===8<----------------------------------------
$ tlmgr --usermode info --only-installed
===8<----------------------------------------

There was simply no output when a long list of texlive packages were
expected. So --only-installed was omitted to see if allowing cloud
access would change anything:

===8<----------------------------------------
$ torsocks tlmgr --usermode list

tlmgr: Local TeX Live (2022) is older than remote repository (2024).
Cross release updates are only supported with
  update-tlmgr-latest(.sh/.exe) --update
See https://tug.org/texlive/upgrade.html for details.
===8<----------------------------------------

This seems to imply that users cannot list packages unless their
texlive installation is the same version as that of the remote
repository. That’s a bit drastic to simply get a list of packages and
many Debian users would not want to update the whole texlive
installation outside of the apt manager. Ideally, apt would have
installed a configuration where the tlmgr-configured repository is
aligned with the Debian version. To check the repo, I ran this:

===8<----------------------------------------
$ tlmgr option repository
(running on Debian, switching to user mode!)
(see /usr/share/doc/texlive-base/README.tlmgr-on-Debian.md)
Default package repository (repository): https://mirror.ctan.org/systems/texlive/tlnet
===8<----------------------------------------

There was mention of “update-tlmgr-latest(.sh/.exe) --update”. This
script is not installed and in fact apt-file search does not find it
in the Debian repos. The webpage https://tug.org/texlive/upgrade.html
suggests installing texlive 2024 and says it can be done without
tampering with the existing installation. But still, texlive is huge.

So the sensible approach appears to be to find a mirror that matches
the locally installed version. The PDF guide mentions this location:

https://ctan.org/mirrors/mirmon

That list of mirrors does not mention which texlive version is
available. It seems having a version-aligned repo is critical to using
tlmgr but the guide does not cover how to find a compatible mirror.

Having read this doc:

  /usr/share/doc/texlive-base/README.tlmgr-on-Debian.md

it’s unclear if tlmgr can safely accomplish the ultimate mission I had
planned: to gracefully downgrade the acro package and pin that older
version. That doc suggests using apt, which is generally sensible but
in the case at hand it’s too blunt of a tool for that considering the
acro package is bundled with in texlive-latex-extra with other apps I
would not want to donwgrade. Nonetheless, tlmgr was provided and IMO
at a minimum should offer the basic functionality of listing packages
and versions without changing the installation.

Hi Manny,

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.

For example, tlmgr info does not work because we don't have a tlpdb
at hand.

Yes, that is the meaning. I think this is obvious enough.,

See above.

You need to point it to the last available 2022 repository, see historic
TL releases.

Yes.

Don't use tlmgr on Debian if you are not happy with the insufficiences.

Yes, see above, historic
https://www.tug.org/historic/
So for 2022 you can for example
https://pi.kwarc.info/historic/systems/texlive/2022/tlnet-final/

CTAN only carries the most recent release.

The most recent.

No IT CANNOT.

the files are installed by root and apt.
tlmgr can do this when you run upstream TeX LIve, but NOT Debian TeX
Live.

You cannot downgrade but downgrade to older versions of Debian / TeX
Live.

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.

Best regards

Norbert
(author of tlmgr, and author of the TeX Live packaging in Debian)

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.

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.

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.

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.

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.

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.

Hi Manny,

It allows installing packages into $HOME/texmf by setting up tlmgr user
mode with
	tlmgr init-usertree

This is *ALL* documented.

Incorrect. Debian tlmgr runs in usermode, and the documentation of tlmgr
clearly states under the heading of usermode that not all actions are
supported.

No need. Just read the section on usermode.

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.

Read the man page.

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.

Please, look a bit more carefully. There is a directory
	tlpkg
which contains the tlpdb, and a directory for the actual packages.

Yes, because you didn't read what I wrote:

This included the correct tlnet-final

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.

See above. tlmgr works ONLY on your TEXMFHOME

It is not. It does *exactly* what it is supposed to do. List the
packages you have installed via tlmgr into $TEXMFHOME.

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.

No. tlmgr *CANNOT* and is *FORBIDDEN* to change files that are installed
by apt. Full stop.

No need to run as root.

Yes, in usermode, clearly stated in the output of tlmgr.
I think I mentioned that already?

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" feature in tlmgr itself, and then included tlmgr in this
restricted mode in Debian.

Anyway, I am not anymore the maintainer. But I think the decisions I
made are still valid. And the documentation is all there.

If something is incorrect in the documentation of usermode or things
don't work as expected in usermode, I am open for bug reports - sent to
the TeX Live mailing list, not Debian. I will be happy to fix them.
But the behavior that is advertised in Debian is what is documented in
the manual page.

Maybe we should make the banner with the usermode warning like MUCH
BIGGER!

***************************************************************
****************** WARNING ************************************
***************************************************************
Because you are using tlmgr as provided by Debian, tlmgr will
run in **usermode**.
Before continuing, read the section on usermode in the manual of
tlmgr, available by typing
	tlmgr help
***************************************************************

But I think people will get annoyed seeing this every time.

Best regards

Norbert

  ~/.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?