[tex-live] TeXLive-2018 fails to update across firewall

[Blumenthal, Uri - 0553 - MITLL]

>> I'm pretty sure it uses the system-provided curl. And again, am very happy about that. 
> 
> TL does not provide curl, it needs to be provided by the system. But it
> is not necessary.

Not necessary in what sense? If LWP works, then nothing else is needed. If it doesn’t work (for whatever reason), then reverting to what’s installed on the target system seems a reasonable fallback.

>>    THis is *really* surprising... WHY did it choose wget from the system,
>>    it should have taken the one provided by TL ... I need to find out why.
>> 
>> Can you please make an option for the user to force using the system-provided wget? Pretty-please?
> 
> What for?

So it would work (a) on systems like mine, and (b) with the current web servers that now usually insist on https, and often rewrite the URL switching to https: on their own.

> On Mac it will probably never hit wget anymore. With the
> latest update you included, the logic is now
>  - by default try LWP
>  - if that fails and curl is available, try curl
>  - if that fails, use wget

But which wget? The one that’s shipped with TL doesn’t cut the mustard.

> Now since curl is always available on MacOS, I guess that wget will
> never be used on.

You may be right in this. Still, I see no harm in allowing for wget - some installations may have curl broken. I know it took me some time to get it working, and it wasn’t a high priority because wget was there, doing the job.

> And, in addition, there is already a way to force TL to use
> different programs. I quote from the tlmgr man page:
> 
>    "TEXLIVE_DOWNLOADER"
>    "TL_DOWNLOAD_PROGRAM"
>    “TL_DOWNLOAD_ARGS"

Ah. I wouldn’t be able to use these with TeX Live Utility, but they should work with tlmgr?


>        These options allow selecting different download programs then the
>        ones automatically selected by the installer. The order of selection
>        is:
> 
>        1.      If the environment variable "TEXLIVE_DOWNLOADER" is defined,
>                use it; abort if the specified program doesn't work. Possible
>                values: "curl", "wget". The necessary options are added
>                internally.

What about path? What if a system has more than one wget or curl installed? E.g.,

$ type -all curl
curl is /opt/local/bin/curl
curl is /usr/bin/curl
$

>        3.      If LWP is available and working, use that (by far the most
>                efficient method, as it supports persistent downloads).

Makes sense.

>        4.      If curl is available (from the system) and working, use that.

Makes sense.

>        5.      If wget is available (either from the system or TL) and
>                working, use that.

I’d much rather use my wget than the TL-supplied one.

>        TL still provides "wget" binaries for some platforms, so some download
>        method should always be available.
> 
>> I wouldn't mess with it, if it worked! 
> 
> It works, right?

Now it does, thank you! But it didn’t when I had to mess with it.

>> Maybe it would be possible to use system-provided (instead of TL-packaged) wget and/or curl when LWP doesn't work? And allowing the user to choose between system-provided and TL-provided?
> 
> As I said, and explained in the excerpt from the man page, it is curl that 
> will be used.

I guess that’s fine.

Thanks!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/tex-live/attachments/20180620/beb392a2/attachment.html>