[27043] trunk/base/portmgr

Juan Manuel Palacios jmpp at macports.org
Tue Jul 17 00:14:29 PDT 2007


	Hi Mark! Thanks for getting down to this! My amendments:

On Jul 17, 2007, at 1:46 AM, markd at macports.org wrote:

> Juan Manuel Palacios <jmpp at macports.org> on Monday, July 16, 2007 at  
> 1:29
> PM -0800 wrote:
>> 	Thanks for inquiring about this, I was just about to write to you to
>> request inclusion in the new guide ;-) The base/portmgr/mprsyncup and
>> base/portmgr/rsync.repos files explain in their comments all that's
>> needed to replicate our rsync mirrors locally, for instance on a
>> server that wishes to supply local clients with faster sync/
>> selfupdate functionality off its own rsync server (not having to
>> travel all the way to California if you're around the globe). Note
>> that this is not exactly mirroring, as the example server would be
>> doing the exact same thing rsync.macports.org is doing when setup
>> with those two files, but independently of it (therefore  
>> "replicating").
>
> Got it.  Here is my description.  Sound good?  Are the terms I use ok?
>
> "You may setup an rsync replication server on your local network to
> minimize internet delay and bandwidth when performing MacPorts
> selfupdates. An rsync replication server pulls the latest rsync data
> (MacPorts base and port sources) from the remote MacPorts rsync  
> mirrors
> via selfupdate, and then serves as the rsync source when rsync  
> replication
> clients on the local network perform selfupdates."

"You may setup an rsync replication server on your local network to
minimize internet delay and bandwidth when performing MacPorts
sync and selfupdate operations. An rsync replication server pulls the
latest necessary data (MacPorts release & development sources and
the ports tree) from the remote MacPorts svn server via the
base/portmgr/mprsyncup script and then serves up the results as the
rsync modules used by the replication clients on the local network  
that perform
the sync and selfupdate operations, per the configurations on the base/ 
portmgr/rsync.repos
file."


	That was both correcting the technicalities and trying to stick to  
your writing style ;-) Keep the technicalities but feel free to reword  
it if necessary. One thing that's not included there is my note about  
periodicity and my urge to discuss it with portmgr prior to setting up  
a replicant server.

>
>
> 1) What are the functional roles of the scripts mprsyncup and  
> rsync.repos?


	mprsycnup is the script that bootstraps the rsync modules off the  
MacPorts svn server; rsync.repos is an rsyncd.conf mockup  
configuration file explaining how the replicant rsync server should be  
setup (actually, rsync.repos details exactly how the main macports  
rsync server is configured).


> As far as the server, I don't get REPOROOT as far the scripts.
>
> 2) Where do I set REPOROOT?  mprsynup only has it in descriptive  
> comments,
> and it isn't in "Paths we'll work on:", and rsync.repos has no single
> occurance where it can be set that I can find.  Shouldn't there be one
> line somewhere with REPOROOT = /path/to/default/reporoot to  
> uncomment?  Ah
> wait!  Is REPOROOT supposed to be named RSYNCROOT?


	Totally! Just corrected that in my latest commit to the files  
(r27065), thanks for noticing ;-)

	mprsyncup does use the variable name for runtime substitution based  
on the initial definition (line 43), as any bash script would do. But  
rsync.repos only mentions it in its comments as the rsyncd.conf file  
does not employ keyword substitution that I know of (would be  
lovely!); therefore the path is explicit and hardcoded throughout the  
file. The variable is mentioned, though, in the file comments to  
emphasize that the hardcoded path in rsync.repos has to be the same as  
the value of RSYNCROOT in mprsyncup, or otherwise the rsync server  
will be feeding something different from what the script prepared.

>
>
> 3) Does one set rsync.repos to run in cron also, along with  
> mprsyncup?  It
> says I need an rsyncd.conf?  Where, how?


	mprsyncup has to run off cron/launchd with a suitable frequency,  
otherwise the rsync repos become stale rapidly (and we get an  
unnecessary amount of support requests). rsync.repos provides a  
working base for a suggested rsyncd.conf file, to which the rsync  
server has to be pointed (where ever it's installed, whether that's / 
etc, /usr/local/etc, /opt/local/etc, etc.. ;-)

>
>>
> See what I have so far in "Using MacPorts" section 3.4.


	Will do, but maybe tomorrow as it's alraedy 3am here and I got bills  
to pay, Sir! ;-)

>
>
> Mark
>


	Thanks again for your hard work on the guide! Regards,...


-jmpp




More information about the macports-dev mailing list