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

[jfbu]

Hi

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 
> 
> /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 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/
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
2020/bin/


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/ 
directory

Best,