Re: Texlive

[Andreas Enge <andreas@enge.fr>]

On Sun, Mar 15, 2015 at 10:50:05AM +0100, Federico Beffa wrote:
> If I understand correctly then the two packages, texlive and
> texlive-small, will essentially be independent.

Yes, and mutually exclusive: If you install both, then there will be lots
of collisions with an unpredictable outcome.

> It would be nice to have an incremental strategy with a hierarchy, say
> texlive-base, texlive-common, texlive-extra, texlive-all, where each
> package is non-overlapping with other ones. Then a new functionality to
> aggregate packages into a new package where you specify which packages
> to include. Something like
> guix package --aggregate texlive --with texlive-base texlive-common ...

I agree, but did not find a way of doing it. The problem with texlive is
that part of the aggregation takes place in the install location (which for
us would be the store).

For instance, "mktexlsr" creates a file
  /gnu/store/pvhfl19r2v7fn00g45jkv32n211bk90h-texlive-2014/share/texmf-dist/ls-R
(after applying the patch), which contains the result of running "ls -R"
inside the directory. This could be done inside the user profile, but not
with the current setup, where
  $HOME/.guix-profile/share/texmf-dist is a link to the store directory
(which is a useful feature we added at some point in time, since it avoids
the need for symlinking the thousands of files inside this directory tree),
so that the ls-R file would be tried to be created in the store.

Then there are the calls to updmap-sys and fmtutil-sys, which I did not
look at in more detail. The latter seems to create files
texmf-var/web2c/*.fmt; it may be possible to create them by chunks and to
merge them in the profile (and then do the "ls -R"-business).

In non-functional (:-)) distributions, the problem is solved by recreating
a global configuration upon installation of an additional package.

So there may be better ways, and anybody is welcome to look into them!
My patch makes a first step by separating things better.

Andreas