little glitch with trying to use update-tlmgr-latest in a darwinlegacy context

jfbu jfbu at
Wed Mar 3 09:30:24 CET 2021


Quoting my initial post:

Le 2 mars 2021 à 13:58, jfbu <jfbu at> a écrit :

> sh -- --upgrade
> Verifying archive integrity... All good.
> Uncompressing TeX Live Manager Updater  100%  
> ./ updating in /usr/local/texlive/2020...
> ./ tlmgr version says this is TeX Live 2020,
> ./ and this updater script created: Tue Mar  2 02:25:21 CET 2021.
> ./ ok, doing full release upgrade  from 2020 to 2021.
> ./ 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
> ./ 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 
> /usr/local/texlive/2020/tlpkg/installer/xz
> 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
> /usr/local/texlive/2020/bin/
> contains to sub-directories
> x86_64-darwinlegacy
> and
> x86_64-apple-darwin13.4.0
> (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 
> /usr/local/texlive/2020/bin/x86_64-darwinlegacy
> so I feel the above rather relates to some hard-coded context
> in

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/
alongside bin/x86_64-darwinlegacy/.

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
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 mailing list.