pretest: error with tlmgr and lz4 backups

[Johannes Hielscher]

Hi,

I installed TL via install-tl some 12 hours ago and now ran `tlmgr
update --self --all` for a first time. I'm impressed about 68 updates
per just half a day (-: , and I got an error message for each updated
package:



/path/to/texlive/2019/bin/x86_64-linux/tlmgr: Couldn't
compress /path/to/texlive/2019/tlpkg/backups/velthuis.r47198.tar
[64/68, 06:06/06:24] update: velthuis [5007k] (47198 -> 50169) ... done
Incorrect parameters Usage :
      lz4 [arg] [input] [output]

input   : a filename
          with no FILE, or when FILE is - or stdin, read standard input
Arguments :
 -1     : Fast compression (default) 
 -9     : High compression 
 -d     : decompression (default for .lz4 extension)
 -z     : force compression
 -f     : overwrite output without prompting 
 -h/-H  : display help/long help and exit



and so on. I'm on x86_64-linux (Debian Stretch) with lz4 installed from
the official liblz4-tool package (version "0.0~r131-2+b1", man page
dated 2015-03-21).

In fact, the backup directory contains all the backup tarballs, but
uncompressed, since the command line to lz4 is wrong.

Seemingly, the "--rm" flag (used in tlpkg/TeXLive/TLConfig.pm) is a
rather recent addition to the CLI of lz4. It is too new to be understood
by Debian stable's lz4 binary. Probably other platforms are affected by
this, too (at least, the versions on FreeBSD 10.3 and Archlinux are
recent enough to accept --rm).

Possible workarounds:
  * If an lz4 binary is provided by the system, learn about its
    capabilities (by version number, or a test run, or a platform
    whitelist/blacklist). In case of doubt, prioritise TL's own lz4
    over it, or switch to another compression algorithm (or no
    compression at all)
  * Always use TL's lz4 binary, regardless of what the OS provides
  * Don't rely on a working --rm, and delete the uncompressed backup
    tarball by a separate step after compression
  * some clever solution that didn't come to my mind.

Best,
Johannes