1

Integrating a vanilla installation of TexLive into the package management tool is obviously important. I am dealing with Tex Live 2016 and Ubuntu 14.04 LTS. Information on how to do that for a Debian/Ubuntu system is already given at this page at www.tug.org.

There, it is recommended to edit a texlive-local file for which a template is available from this page at www.tug.org. Such a template, however, applies to full-scheme installations (46 out of 47 package collections, in the order of 4+GB).

In my case I have chosen a medium-size installation scheme (23 collections). The excerpt of my install-tl.log file can be looked at here.

  • Should I then adapt the template to the texlive-local file to this reduced installation before I move on in the integration?

  • If so, how do I tailor texlive-local? The log file lists a good 1002 packages (medium-size), while the full-size texlive-local shows much fewer dependencies, with an own naming. Connecting the two is quite not intuitive.

  • Also, I do expect that in the future I might need to install some other package, hence collection, again in vanilla mode. Will I need then to edit the texlive-local accordingly each time I add a collection to the bunch in place?

In my research I came across this post on this forum that rephrases the same sources as above and does not cover the case of partial installation.

1 Answer 1

2

I strongly recommend installing the full scheme. Not only is this generally much easier, in this case it will make life much, much easier.

If you choose not to do that, you must decide between the following 2 options.

Option 1

Use the standard dummy package to tell apt that everything is installed, even though it isn't. If you install something which depends on a missing part of TeX Live, you will obviously receive no warning. You will, therefore, need to scrutinise package dependencies yourself and ensure that they are satisfied by installing whatever additions are required using tlmgr.

Option 2

Prepare a tailored dummy package to tell apt what is actually installed. To do this, you will need to map the collections you installed with tlmgr onto Debian package names. This means you will need to figure out what is contained in each installed collection and which package(s) this is equivalent to in Debian.

Note that Debian's packaging will not correspond 1:1 with TeX Live packaging. Debian probably makes meta packages available which pull in many actual packages and you generally want your dummy package to use the highest level package you can, because this is more likely to persist through time. In any case, you may find that you need to install additional things to make up a complete Debian equivalent using tlmgr. Moreover, both Debian and TeX Live packages change over time, so you will need to regard this as a work-in-progress and review your dummy package when either side alters their packaging. The lower the level of the package names specified in your dummy, the more frequently you are likely to need to update it. In general and assuming a reasonably standard TeX Live scheme, this should probably not be too much trouble in practice, but it does require a certain degree of vigilance.

When you install Debian packages, you will need to ensure that you are not inadvertently bringing in Debian TeX Live packages as dependencies. When apt wants to do this, you will need to abort the installation, identify the equivalent TeX Live packages, install them with tlmgr, update the dummy package spec, rebuild and reinstall it, before proceeding with the original installation.

To some extent these issues hover anyway, even with a full scheme installation because package names change over time and this can render your dummy package useless. But the issues are obviously greater with a partial installation of TeX Live. They can be mitigated by matching your package choices to high-level Debian meta-packages and by ensuring that your TeX Live installation includes everything likely to be required by the Debian software you install later. But packages sometimes have surprising dependencies, so you cannot rely on this, but can use it as a strategy to reduce the need for later reconfiguration of your dummy.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .