[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: documentation in TeX Live collections

From: Nicolas Goaziou
Subject: Re: documentation in TeX Live collections
Date: Mon, 28 Aug 2023 13:01:53 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)


Emmanuel Beffara <> writes:

> Yet, as far as I know, most packages in Guix (apart from texlive-* ones) come
> with their documentation, so it feels somewhat inconsistent.

Every texlive-* package comes with its documentation, in a separate
output. "doc" output are not uncommon at all in Guix. Therefore,
I disagree with the inconsistency you're talking about.

> not including the docs in the main outputs can make sense, especially given
> the volume it represents. Anyway, given that there is extensive documentation
> in TeX Live, it seems only natural to have it easily accessible.

Barring the `texdoc' issue, documentation is easily accessible; you just
need to install the "doc" output of the package you're interested in.

>> Would the following definition for texlive-texdoc solve both issues
>> mentioned above? (the warning and the error.)
> [...]
>>                (add-after 'link-scripts 'wrap-programs
>>                  (lambda _
>>                    (wrap-program (string-append #$output "/bin/texdoc")
>>                      '("GUIX_TEXMF" = ("${GUIX_TEXMF%:*}"))))))))
> It would certainly remove the warning but it would make only the first path
> usable by texdoc, while other tools seem to support having several paths in
> GUIX_TEXMF. Besides, I don't understand how GUIX_TEXMF is taken into account
> by the various tools. Web2c and co don't know them, so there must be some
> wrapping or patching somewhere in the package definitions?

It seems some programs do handle it fine, e.g., tlmgr, but not all of
them (e.g., texdoc or chktex). In any case, I don't know enough about
this part of the code to answer this.

> Is there a way to diagnose that kind of thing? I stumbled on a similar
> behaviour in other contexts and was unable to investigate it (in my case, big
> debug versions of Qt libraries are often downloaded, although I neved
> requested any debugging version of anything).

Usually, there is `guix graph --path package1 package2', which explains
why package2 is installed along with package1. I couldn't get any
meaningful result in this case.

>> If that's a common request, we could add a `texlive-collection-foo-doc'
>> package that would propagate all "doc" outputs from all packages
>> included in `texlive-collection-foo'.
>> However, I'm a bit reluctant to add more artificial packages (i.e., not
>> known to TeX Live distribution). Also, it might be as simple to do it in
>> one's own manifest.
> I think it would make much more sense to have "doc" outputs also for
> collections and schemes. It would be consistent with the structure of
> individual packages and would not require artificial packages.

I disagree. Collections are meta-packages. There is no documentation,
nor content, attached to them. Moreover Guix meta-packages do nothing
special about the documentation of packages they propagate. This would
be inconsistent.

> Having individual package documentations in one's manifests is of course
> doable but it is contradictory with the approach of collections.

How so?

In any case, I suggest to write a proper bug report for this. Hopefully,
someone with better understanding about the implications of GUIX_TEXMF
will be able to solve this.

Nicolas Goaziou

reply via email to

[Prev in Thread] Current Thread [Next in Thread]