[tex-live] Using tlmgr/TeXLive utility to install local versions of a package
Alan Munn
amunn at gmx.com
Mon Aug 8 17:34:04 CEST 2011
On Aug 7, 2011, at 7:31 AM, George N. White III wrote:
> On Sun, Aug 7, 2011 at 7:40 AM, Norbert Preining <preining at logic.at> wrote:
>> Hi Alan,
>>
>> PLEASE STAY ON LIST!!!
>>
>> On Fr, 05 Aug 2011, Alan Munn wrote:
>>> For complex packages like pgf and beamer, for example, or some of the things that now depend on latex3, it's sometimes useful to keep the old version in the main tree and test out the newer version separately. Installation for small packages is obviously quite easy, but for larger ones with dependencies it would be nice to use tlmgr for the task.
>>
>> You can alway make a manual backup before updating with tlmgr, and then
>> revert to the previous version.
>
> When doing such tests, I often use side-by-side comparisons with
> old and new versions available in side-by-term terminal windows. A
> brute-force approach uses two machines, one or both of which can
> be virtual. TeX Live makes this quite easy as you can simply copy
> an existing tree from one system to another.
>
> If you use linux or something similar, OS "features" exists to
> support such testing for things that have nothing to do with TeX Live.
>
> On a system that supports hard links, e.g., linux, make a snapshot of the whole
> texlive system, e.g., 'cp -drlp 2011 2011-test', then test the new version of a
> package in 2011-test. By using hard links, the copy runs quickly and uses
> little space. Note that some tools may alter both the linked copy and the
> original, while others only alter the one specified, so you need to RTFM
> and perhaps do some tests.
>
> Overlay filesystems are another way to make tests, but you loose
> the side-by-side benefits: <http://en.wikipedia.org/wiki/UnionFS>
>
> In some cases (e.g., integrated editing environments that store
> the paths to the tex binaries, or when using symlinks for
> /usr/bin/tex, etc.) it is not convenient to simple adjust
> the PATH from, e.g., texlive/2011 to texllive/2011-test. Such
> problems can be solved using "bind" mounts, e.g.,
>
> mv /usr/local/texlive/2011 /usr/local/texlive/2011-orig
> cp -drlp /usr/local/texlive/2011-orig /usr/local/texlive/2011-test
> mount --bind /usr/local/texlive/2011-test /usr/local/texlive/2011
Thanks for these suggestions. I'm using a Mac, so they are all implementable. My original intention wasn't to have two duplicate distributions, but I see how this would also be a way to solve the problem.
>
>> I see that it might have usage patterns, but the problem is that it opens
>> a can of worms, because then sometimes the package in TEXMFHOME will be
>> much older than the one in main, but we cannot report on that.
>
> I've been involved with TeX for a few decades -- the most common source of
> problems was and remains older versions of included files being found in
> a document directory or in texmf tree outside the "TeX system".
This is definitely true. Has anyone ever written a script that searches for duplicates between the local texmf and the main one? It would be quite useful.
>
> It doesn't make sense to start making tricky changes to TL package
> management when generic OS tools are available.
Fair enough. I wasn't suggesting we do, just asking if it was possible at the moment.
Alan
--
Alan Munn
amunn at gmx.com
More information about the tex-live
mailing list