> 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:


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:


which failed:

/usr/bin/tlmgr: TLPDB::from_file could not initialize from: 
/usr/bin/tlmgr: Maybe the repository setting should be changed.
/usr/bin/tlmgr: More info: https://tug.org/texlive/acquire.html

There seems to be a presumption of TeX expertise on users. So then I
tried the path verbatim as you suggested:

$ tlmgr option repository 
$ tlmgr --usermode info --only-installed
(no output)

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

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.

Reply via email to