MacPorts from behind proxy servers & fetching the file directly

Rainer Müller raimue at macports.org
Fri Mar 16 16:42:09 UTC 2018


On 2018-03-16 12:31, Mojca Miklavec wrote:
> While discussing GSOC with Umesh, he repeated what we already
> discussed during the meeting. Students in campuses (including the one
> where he is studying and from which roughly 40 students participate in
> GSOC each year) might be behind proxies and might not even be able to
> run MacPorts due to blocked rsync.
> 
> If you try to install the software and not even the installation works
> ... well, then you probably go for alternatives. I didn't want to
> point this out in the context of GSOC, but just wanted to provide an
> example of things that could drive our potential users and developers
> away.

rsync is currently in use for two operations in MacPorts. When thinking
about replacing rsync, they need to be looked at separately.

1) sync: updating the ports tree

We have two alternatives that work over HTTP(S), but they need to be
manually configured by the user.

https://trac.macports.org/wiki/howto/PortTreeTarball
https://trac.macports.org/wiki/howto/SyncingWithGit

The main goal should be to find a way to incrementally distribute ports
tree updates over HTTP while still being able to guarantee the integrity
with signatures.

2) selfupdate: to upgrade base

No alternative exists, users that cannot use rsync have to install base
updates from the .pkg installers.

See https://trac.macports.org/ticket/38265

> Umesh was only able to work on MacPorts because he was at home during summer.

That sounds really drastic, but I do not think it is in reality. There
are the alternatives for syncing the ports tree as listed above.
Development on base does not need rsync in any way. Most people that end
up hacking on base have usually contributed to the ports tree before and
therefore are more likely to be using git already anyway.

Rainer


More information about the macports-dev mailing list