[OS X TeX] TDSXplorer

[Dr. Clea F. Rees]

On 06/09/08, you seem to have written:

> Well, this beast does not exist
>
>
> The shortcomings of tlmgr are
>
> 1) Cannot list packages which are not in your tlmgr installation  but
> remotely available with tlmgr

Surely it can do this, can't it? If the package is installed, an "i"
appears before the item. If not, there is no "i". Maybe I'm not
understanding you correctly, though.

> 2) Currently tlmg knows nothing about (texmf-local or ~/Library/texmf
> ). If you have obsolete version of package sitting there, no matter
> how tlmgr updates /usr/local/texlive/2008/texmf-dist/ it will have no
> effect until you manually remove the package. Those who used mpm
> should take care of this tree as well (probably the best thing would
> be to remove it completely and remove mpm itself)

It isn't just that it doesn't know about the local/home texmf trees. It
does not actually look at the main TL tree either. What I mean is that
it isn't as though it could "also look" at packages in the additional
trees. That isn't how it works. It relies on a database (if that's the
right term) which describes the contents of the TL tree.

This also means it relies on the accuracy of that database. If, for
example, the database says that fontinst is at version 1.928 when the
installed version is actually 1.927, tlmgr will never recognise the
existence of the newer version. (Unless a later version of fontinst is
released, of course.)

At least, I've been trying to make sense of it and I think this is how
it works. It seems to use /usr/local/texlive/2008/tlpkg/tlpobj/*.tlpobj
and /usr/local/texlive/2008/tlpkg/texlive.tlpdb as sources of
information about the current state of the tree.

I've started going through the documentation but a lot of it seems to be 
out-of-date (or maybe inapplicable to the MacTeX version?).

In any case, if I've understood it correctly, does anybody know if
there is a documented/advisable way to correct inaccurate database
information e.g. to alter the version number of a package so that it
matches the installed version?

Or would this not help? Maybe what's in the database reflects the way
packages are assembled for TL so although tlmgr would then try to
update the package, this would merely reinstall the existing
out-of-date version?

I'm not quite clear yet about the relationship between packages on CTAN
and packages in the (remote) TL tree, so to speak. If these are
distinct, presumably the only solution would involve changing the remote 
TL package as well as correcting the information in the local
database...?

- cfr