TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Every year TeX Live provides a new version. My recollection is that soon after a new version is released, the old version's tlmgr stops fetching updates to packages. They provide upgrading instructions with the disclaimer

This procedure is not bullet-proof, or especially recommended

There is no upgrade path for Windows. Looking at the release history, it is not clear to me what is actually changing between releases such that a full new install is required/recommended. I always thought of TeX Live as providing useful binaries (e.g., pdflatex, biber, and makeindex) and a convenient way of updating CTAN packages. What am I missing? Why does TeX Live need a new install every year?

share|improve this question
+1 for this interesting question. – Marco Daniel Apr 5 '13 at 12:43
Maybe just because of legal issues? – Mario S. E. Apr 5 '13 at 13:07
I don't think of legal issues, @MarioS.E. Due to legal issues, some packages are removed, if they are not licensed correctly, but this happens automatically during update with tlmgr update command. – Stephan Lukasczyk Apr 5 '13 at 14:39
@DanielE.Shub: biber is special case as the binary is built by its developers not TeX Live builders. – Khaled Hosny Apr 6 '13 at 9:51
biber is built using the excellent Par::Packer module of Perl (and biber is all perl). The build process is not like any other TL binary as a result and it would have been hard to get all the TL servers updated with the necessary things. So I have a build farm of VMs to do this myself. It makes for a more rapid dev cycle as I control the VMs. – PLK Apr 24 '13 at 18:50
up vote 66 down vote accepted

Ok, here's an answer as the main developer of tlmgr and the whole TeX Live infrastructure. You have to decide two things:

  • the freeze period before release of a new version
  • upgradability from one release to the next

Concerning the former, freeze period: Normally during the year we do not make updates to the actual binaries, but only to scripts and the packaging. That means, that in preparation of a new release all the binaries have to be recompiled, which is a huge tasks and involved lots of time, and iterations. Bugs are fixed, code adapted so that it builds on all platforms (and there are many!). During this time we do not want to make partial upgrades of some binaries, because sometimes that needs to be accompanied with library file updates.

Another point is that during the freeze period critical new features are sometimes included in the texlive infrastructure and the tlmgr, which would be too dangerous to be released to the world in the normal course.

And finally, it is also about getting into a state that can be pressed onto DVD.

Now for the upgradability between releases: The reason in the first years were changes in the internals that did not allow upgrades (like format of the internal coding of options, etc.). This was in the first years (say 2008-2010) the most common reason. A normal upgrade was simply not trivially possible. Of course, one could write an upgrade script and make an NSIS installer for Windows, but we do not have time for that. We are volunteers and have to concentrate on the important things.

In the last years (say since 2010) there always was an upgrade procedure, although we normally didn't give it a lot of testing; that is the reason why we don't recommend it. Disk space is nowadays quite abundant, and having two installations in parallel is thus not such a pain. But still, there always was the way to upgrade.

On Windows this is unfortunately not so trivial, as the uninstaller and the registry etc etc is linked to release years, it is simply a pain on Windows, but that is a special case.

Finally, one more reason: In many cases in the last year, an update or a new installation would not have changed much in the amount of downloaded data, as often all the packages were updated in one way or the other (due to internal changes), which meant an upgrade would have involved downloading all packages, just like the installation.

I hope that all this makes our intention a bit more clear, and if there is anything unclear, or if someone has better ideas how to deal with it, we are open to suggestions!

share|improve this answer
Thanks for your work. – Marco Daniel Apr 6 '13 at 14:32
I appreciate this answer from the lead developer. Can you answer the question I posed to @vonbrand in my first comment: why does the entire CTAN tree have to be considered "maintained" by the TeX Live team, to the extent of binding its upgrades to the yearly releases? Whereas with Linux the distro maintainers are to an extent the package maintainers as well, does TeX Live do any patching of packages or just provide them as-is? And if the latter, why not allow continuing updates? – Ryan Reich Apr 6 '13 at 15:39
Why not continuous updates: please read my answer, it has nothing to do with the packages itself as they are on CTAN, but with our internal repackaging and format of distribution. We don't change the CTAN packages at all! It is all about internal changes, as I wrote. – norbert Apr 7 '13 at 3:14

I can't speak for TeX Live in particular, but I have been involved with Linux distributions from their very beginning, and I believe my observations there are relevant for TeX Live too (both are collections of disparate pieces that have to be selected, integrated and convinced to work nice together, each piece evolves at their own pace).

While in a perfect world such a software collection would be maintained forever, this isn't practical. New packages show up, old packages are overhauled, some packages are superseded by new ways of getting the work done. To maintain, say, TL-2011 would mean to keep "the old way" working, even if upstream has abandoned the package (or changed it so much that it isn't a drop-in replacement anymore). That means endless backporting and fixing old bugs. Volunteers for that are only found among dyed-in-the-wool masochists.

TeX Live maintenance requires knowledgeable people in a rather esoteric area, and those are in very short supply. Either they maintain 2011 forever (and no 2012, 2013, ...) or they concentrate on building and shipping the last version. Besides, working on shiny&new is always more fun, so there is more potential to attract new recruits there.

Perhaps they are enough to keep two versions reasonably up to date, but I guess not (as they have decided that they don't have the manpower, so mandatory yearly upgrade).

share|improve this answer
Makes complete sense to me – Mario S. E. Apr 5 '13 at 13:15
This doesn't answer, though, why the entire CTAN tree needs to be considered "released" on a yearly basis for TeX Live purposes. Though dependencies are resolved by tlmgr, it would be almost trivial to add a switch "--no-deps" that just installs the explicitly requested packages, and make that switch mandatory in outdated releases. Along with forbidding updates of the stuff that's actually maintained by the TeX Live team, this could keep old releases usable indefinitely without extra work. So I interpret the question as asking: why not do this? – Ryan Reich Apr 5 '13 at 13:56
Rarely, do I have to do a complete reinstall of my Linux distribution. For example, when Debian moves from Squeeze to Wheezy, upgrading will (hopefully) be as easy as apt-get dist-upgrade. When you "upgrade" TeXLive it downloads all of the packages again from CTAN. That just seems silly (but I am guessing there is a reason). – StrongBad Apr 5 '13 at 14:03
@RyanReich, the --no-deps and such road leads to what I have installed is completely different from yours, each breaks/malfunctions in endearingly different ways due to missing dependencies. That means a even much greater burden in maintenance than having several versions in parallel. Been there, seen that done (participated a bit myself), seen the resulting suffering. – vonbrand Apr 5 '13 at 14:19
That's not what win-win usually means... – Ryan Reich Apr 5 '13 at 17:20

in addition to @vonbrand's excellent answer, one important reason to upgrade and "freeze" tex live annually is to provide a stable snapshot on physical media, largely for the benefit of members of the various user groups, but also for tex users who don't have convenient internet access.

this dvd (it no longer fits on a cd) is also physically packaged with some (la)tex-related books, particularly in germany; this (commercial) packaging is the reason why anything with a restrictive (non-free) license must be excluded from the collection.

share|improve this answer
I can understand the need to take and release snapshots. What I don't get is the need to reinstall. It seems tlmgr should be able to update the entire release (it has a mechanism to update itself). – StrongBad Apr 5 '13 at 14:33
@Daniel sometimes the format of the database that provides the information changes, and older tlmgr will not be able to use it. – norbert Apr 6 '13 at 8:39

To add some more information to the answers of @vonbrand and @barbara beeton:

One other reason is to change infrastructural things. Some time ago the tlmgr management tool was introduced with a graphical interface for (mainly) windows users. Also the package format was changed (I think it was from TL2008 to TL2009) from LZO to XZ which was not possible if not requesting a new installation as the whole infrastructure was changed.

But nevertheless it often is possible to update e.g. from TL2011 to TL2012 without any new full installation. But be careful: This is not supported by the developers and is not recommended! It works in some cases and in others not.

I have an hope that there will be kind of a rolling release scheme (as e.g. in Arch Linux or Gentoo), as this was a topic several times on TeX Live's mailing list.

share|improve this answer
I can see how changing the package format would require a reinstall. Interestingly, the TL team put the change to XZ under a miscellany of smaller changes – StrongBad Apr 5 '13 at 17:51
@Daniel E. Shub This was kind of an understatement;-) – Stephan Lukasczyk Apr 5 '13 at 22:47

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.