TeX Live in Linux distributions

A subject which comes up quite a bit is the age of TeX Live systems shipped with common Linux distributions. While the current ‘vanilla’ release is TeX Live 2011, many Linux distributions use TeX Live 2009, or even TeX Live 2007. This leaves many people wondering why. Now, I’m no expert in this area, but reading the various mailing lists gives me some ideas about the ‘time lag’. Some of this is technical, and some is more conceptual.

The first thing to say is that for many Linux users with a personal system, where they can install vanilla TeX Live each year directly from TUG, it’s probably easiest to simply not worry about this entire area and simply install TeX Live themselves. However, a lot of Linux systems are either multi-user or server set ups, and it’s there that a lot of the following is more important.

The technical reason for the delay seems to be the way binaries are ‘linked’ to standard support libraries. To understand this, you first need to know that most programs use third-party code for standard tasks. So for example pdfTeX uses libraries for both .png and PDF support. In the vanilla TeX Live system (on Linux and other systems) these links are ‘static’, and the appropriate support material is supplied as part of the entire bundle. However, Linux distributions link ‘dynamically’. The advantage of the latter approach is that you only have one version of each library installed, and it is easy to update (for example for security fixes).  So re-bundling TeX Live for Linux means building the binaries using dynamic linking. That of course means doing some work, and this is not trivial.

Size is the second stumbling block. TeX Live is big, as it includes a lot of (La)TeX packages and more importantly all of the documentation, mainly in PDF format. On a modern system, the hit in terms of hard disk space is not usually an issue, but at the same time there’s pressure in the Linux world to keep systems small and only install what is needed. So there is work to do in dividing TeX Live up into the constituent parts, a task that seems pretty difficult to me.

Finally, there is a conceptual point. TeX Live is not a single ‘product’, but is instead a bundle of different items from hundreds of different contributors. So while there is an overall TeX Live version, this does not reflect the status of each constituent part. The Linux packaging approach works best when each package has a small development team and a single version. It’s not really so well adapted to the much more diffuse status of items in TeX Live. So you often see discussions about stability, that probably make sense for a single software package but fits much less well for TeX systems.

As I said above, for single-user systems where the user can update TeX Live each year it’s probably easiest to simply bypass all of this. It’s also worth noting that having TeX Live available is a lot better than the alternative.

10 thoughts on “TeX Live in Linux distributions

  1. I have wondered about this as well. I don’t really think the issue is compatibility with shared libraries – the TL team does a lot of work to make sure binaries are broadly compatible. I suspect that the problem is more a combination of nominal package inter-dependencies, the size of TeXlive and the way most distributions configure packages in bite size chunks. I suspect that is a lot of work and is typically done by volunteers. I’d love to see Norbert Preining who is a key player in both the TL and Debian communities share his perspective here.

    My biggest issue is one of dependencies – many packages I use depend on TeX and so want the system TeXlive installed. I just switched from Mandriva 2010.2 to Xubuntu Oneiric and had the same issues on both.

    Happily, I have a big hard drive. I have the system TL installed and have TL2011 installed in /home/shared/texlive (safe from OS upgrades…) and have configured my path so it finds the TL2011 installation. I can easily keep this updated. Kludgy, but it works.

    BTW – this was a lot less of a headache than I had to go through to get OpenCV 2.3 on the system. Happily, I was not the first to figure out how to do this. Google Advanced Search is my trusty Swiss Army Knife…

  2. My point about libraries is that you can’t simply take the ones from vanilla TL and rebundle them. Each distro has to build them appropriately, which is some work in every case (even if it is trivial: I’m not sure that is the case). As you say, it would be handy to have an ‘inside’ view: I’m looking at things from ‘the outside’.

  3. I understand your point about shared libraries. I do have a limited sample size, but have had no problems with the TL binaries on Mandriva 2010 (32 and 64 bit) and Xubuntu (32 and 64 bit.) I know Norbert carefully tests Debian. I’ve followed the pretest work the last couple of years and know many others test as well. That said, other people’s mileage may vary… I wonder how widespread the issues are with the TL-supplied binaries/libs…

  4. @stevem: There are still quite a few packages under both Fedora and Debian that depend on Tetex, IIRC, for the reason that noone has ever put the work into translating their configuration of paths over to TL.

    An additional problem with a system like Debian is that, while the sid (most modern, unstable) distribution is currently TL2009, when it does update, the stable version (currently squeeze), will still have TL2009 because the changes have to work through testing before they are accepted into stable. Since stable is the only version supported by Debian Security Advisories, lots of installation of the kind Joseph describes insist on that.

    A possible solution would be to have something like the Debian Backports system (the similar Fedora Legacy system was discontinued some time back, I gather), allowing more recent packages to be used with an older TL. Even if only the buggiest packages were represented in such a backports scheme, it might help quite a lot of users in distress, and if there were no binaries, scripts, or write18 packages in Texlive Backports, then it might be easy to propagate these changes to the distributions.

    As always, all these kinds of problems can be solved by volunteer work. I’m afraid I’ve never pulled my weight with these things.

  5. In addition to library dependencies (that, I imagine, cannot be that much worse than those of, say, LibreOffice), there is the question of what to do with tlmgr. It is a fantastic tool, but it largely duplicates the function of both linux configuration tools (such as debconf) and package managers (apt-get). I have no idea how tlmgr could be integrated into, say, Debian.

  6. Shared libraries aren’t a significant issue. The TL sources build in just about any combination.

    But your second point is right — TL is (unavoidably) big. So it takes nontrivial effort to make a new release. Distro maintainers, like everyone else, have only so much time, and there aren’t very many of them. So it takes ages for any update to happen.

    Norbert once told me that part of the job for Debian is to review new material (for what, I’m not sure). That is boring and he doesn’t want to do all that himself. All the “real” work for upgrading Debian is done, but barring these reviews, it will never happen.

    At least none of the distros ship teTeX any more (I think :).

    If you want to discuss more about these issues, please email tldistro@tug.org (and see http://tug.org/texlive/distro.html). The TL distro maintainers are all on that list.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.