little glitch with trying to use update-tlmgr-latest in a darwinlegacy context
jfbu at free.fr
Wed Mar 3 09:30:24 CET 2021
Quoting my initial post:
Le 2 mars 2021 à 13:58, jfbu <jfbu at free.fr> a écrit :
> sh update-tlmgr-latest.sh -- --upgrade
> Verifying archive integrity... All good.
> Uncompressing TeX Live Manager Updater 100%
> ./runme.sh: updating in /usr/local/texlive/2020...
> ./runme.sh: tlmgr version says this is TeX Live 2020,
> ./runme.sh: and this updater script created: Tue Mar 2 02:25:21 CET 2021.
> ./runme.sh: ok, doing full release upgrade from 2020 to 2021.
> ./runme.sh: updating /usr/local/texlive/2020/bin/x86_64-apple-darwin13.4.0 ...
> tar: x86_64-apple-darwin13.4.0 : stat impossible: No such file or directory
> tar: Arrêt avec code d'échec à cause des erreurs précédentes
> ./runme.sh: no xz.[x86_64-apple-darwin13.4.0][.exe] binary for /usr/local/texlive/2020/bin/x86_64-apple-darwin13.4.0 in /var/folders/np/4_9pppfs54xdv9m79m7rwx4w0000gn/T/selfgz37288917/installer/xz.
> Turns out that in
> there is only a xz.x86_64-darwinlegacy indeed (actually the file date is March 2, 2019)
> and I don't know if this is relevant.
> I am using indeed a darwinlegacy install.
> To be completely honest, but I don't know if relevant
> contains to sub-directories
> (which comes from me building my own binaries in March 2020)
> However my PATH only contains /Library/TeX/texbin
> where texbin is a symlink which, at the time the above happened
> I had been careful to let resolve to the
> so I feel the above rather relates to some hard-coded context
> in update-tlmgr-latest.sh
As I have now completed the procedure on another darwinlegacy
architecture with the additional precaution to remove from
2020/bin the x86_64-apple-darwin13.4.0/ mentioned in my initial
post which co-existed with x86_64-darwinlegacy/, I am happy
to report the procedure completed with no complaints this time.
Thus, contrarily to my conjecture, the hick-up seems to have been
triggered by the presence of bin/x86_64-apple-darwin13.4.0/
Which suggests the script is influenced by the contents of bin/
(even if bin/x86_64-apple-darwin13.4.0/ was not, as reported,
seen in PATH), rather than the (somewhere recorded information)
that the install was done initially (i.e. in 2020) for
a darwinlegacy architecture.
Notice that, as reported, the presence of bin/x86_64-apple-darwin13.4.0/
is because I also compiled locally the binaries one year ago.
As the ./Build script created in ins/ a directory with this name
there was no reason for me to change the name, once copied over to
I hope my report will not have as result that the update-tlmgr-latest.sh
next year will simply refuse the --upgrade path, simply because
I attempted something nobody else does and reported upon it.
And even though the update script reported a problem, in fact enough
of the architecture was in place for, as I reported yesterday,
tlmgr update --self --all
then to finish successfully the in-place upgrading.
As for why I do that: my Macs being under Time Machine daily backups,
and as I did not intend to keep a TL2020, there was no reason to fill
up my backup disk with 4 to 6 Gigabytes of a new texlive/2021/
More information about the tex-live