guix-devel
[Top][All Lists]
Advanced

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

Re: documentation in TeX Live collections


From: Emmanuel Beffara
Subject: Re: documentation in TeX Live collections
Date: Tue, 29 Aug 2023 10:58:11 +0200

Hellon

De Andreas Enge le 28/08/2023 à 20:05:
> if I understand things correctly, we would like the following behaviour
> for propagated inputs in the texlive context:
> We have these metapackages with propagated inputs; all of these inputs
> have "out" and "doc". Then we would like to automatically create "out"
> and "doc" for the metapackage, into which the corresponding "out" and
> "doc" of their "ingredients" are propagated.
> 
> Well, more precisely, the metapackages are empty, so it is a bit fuzzy
> what I mean by "into which" above.
> 
> We would like the following:
> - If a user installs metapackage:out, they get all the ingredient:out
>   in their profile.
> - If a user installs metapackage:doc, they get all the ingredient:doc
>   in their profile.
> I am quite certain this is not how propagated inputs work, and I do not
> know whether their behaviour could be changed in this way.

Indeed, that is what I imagine. Actually, it does not feel specific to the
texlive context and could apply to propagated inputs in general. 

[...]
> See also
>    https://issues.guix.gnu.org/65550

Interesting! The case of development outputs referred to in this issue
suggests similar concerns.

> I do not really understand what is happening. All outputs are downloaded,
> but only the out outputs are propagated?

It does look like that: all outputs of the propagated inputs are downloaded
but only the "out" outputs are actually propagated to the profile. And indeed,
after guix gc, the other outputs are removed from the store. Is that the
intended behaviour?

> If this is true, then I think it would make sense to not split into two
> outputs, but to always include the documentation in the texlive packages.

I'm not sure about that. Splitting the documentation to a different output
does make sense in itself (for considerations of space, mostly). This thing
about propagating only "out" outputs looks more like an issue with package
definitions, or even the package model if propagating other outputs happens to
be unsupported.

-- 
Emmanuel



reply via email to

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