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!
In your home directory, look in the (hidden) files .bashrc and .bash_profile for lines that include your texlive 2012 path and remove the path. Then add these lines to your .bashrc:
export PATH=/usr/local/texlive/2013/bin/x86_64-linux:$PATH
export MANPATH=/usr/local/texlive/2013/texmf/doc/man:$MANPATH
export INFOPATH=/usr/local/texlive/2013/texmf/doc/info:$INFOPATH
(If you installed texlive somewhere else, or aren't using x86_64, change the paths to point to the correct install directory)
EDIT: I seem to have misunderstood the original question. The above will make sure you're pointing to the correct version of TeXLive (sounds like you might have some 2012 packages installed via your package manager as well). If you want to use a TL installation from a DVD, but packages from your package manager (I don't recommend it, but that sounds like it's what you want to do), you can try creating a dummy TL package so that your package manager will think TL Is installed from it and the dependency chain can be resolved.
Something like the following (from the Tug package on Debian) should do the trick:
- Install vanilla TeX Live as root, system-wide.
- Ensure that the only Debian TeX Live packages installed are tex-common, texinfo, and perhaps lmodern
- Add TeX Live's bin directory to ENV_PATH in /etc/login.defs. [basically what I said above, except that I assume that you might want a different version of TeXLive for different people, hence the use of bashrc).
Tell APT about your TeX Live installation by building a dummy package using equivs:
- $ aptitude install equivs # as root
- mkdir /tmp/tl-equivs && cd /tmp/tl-equivs
- equivs-control texlive-local
edit texlive-local (see below)
- $ equivs-build texlive-local
- $ sudo dpkg -i texlive-local_2011-1_all.deb
At the step "edit texlive-local", edit the Maintainer field and the list of the packages provided by your local TeX Live installation as appropriate. If you installed scheme-full except collection-texinfo as recommended, the file should look like this example.
For more information, see this question.
Best Answer
Yes, you can uninstall 2012 and then install 2013 first.
As long as you change the path variable, Emacs will find it. The path variable can be found by:
Once there, you will see a systems variables box with a scroll bar and this is where you can set and change path variables in Windows.
I don't use Windows so I have not idea what you would change the variable too but that is where you will find it. Also, I am not sure what it will be called but it should be obviously related to TeXLive.