distfile downloads failing on https

[Jan Stary]

On Feb 22 17:09:22, raimue at macports.org wrote:
> On 2018-02-21 20:14, Jan Stary wrote:
> > If I am reading https://guide.macports.org/chunked/reference.phases.html
> > right, there is are no "fetch dependencies". Would it make sense
> > to introduce fetch dependencies just like we have build dependencies
> > and run dependencies, so that the affected ports could specify e.g. curl,
> > and MP vuld use _that_ for those ports?
> 
> depends_fetch exists, but apparently is not documented in the guide.

Thanks for the insight. Currently, nothing is using it,
except: these explicitly clear it (why?)

  ./editors/HexFiend/Portfile:    depends_fetch
  ./editors/textmate2/Portfile:    depends_fetch
  ./python/py-pyobjc-cocoa/Portfile:        depends_fetch
  ./python/py-pyobjc-fsevents/Portfile:        depends_fetch

and this one declares 'git' as its fetch dependency:

  ./multimedia/mplayer-devel/Portfile:depends_fetch-append bin:git:git

(why don't other git-downloading ports declare it too?)

If it is this much unused, wuld it be better to remove it,
as opposed to document it and keep it for this one port?

> However, there should not be individual workarounds in ports,
> as it is a general problem.

Understood. But isn't the whole premise of depends_fetch
to allow for individual workarounds for ports that need
to fetch in a certain way / with a certain tool?

> Sorry, but your system has become too old to communicate
> with servers on the internet. You will experience the same
> problem with more and more servers over time as they begin
> to require TLS 1.2.

Yes. For now, I am using MP that is rebuilt against
a standalone curl that can download from anywhere,
as a workaround on these systems.

> The best workaround would be distfile mirroring, as everyone would
> benefit from that. Most mirrors are still accessible with no TLS or less
> strict cipher requirements.

I can't wait :-)

	Thanks again,

		Jan