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